tcltk-perl Mailing List for tcltk (Page 16)
Brought to you by:
hobbs
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
(174) |
May
(34) |
Jun
(1) |
Jul
|
Aug
(20) |
Sep
(18) |
Oct
(8) |
Nov
(6) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(16) |
Feb
(8) |
Mar
(3) |
Apr
(1) |
May
(9) |
Jun
(1) |
Jul
(4) |
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
|
2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Konovalov, V. <vko...@sp...> - 2004-04-14 09:43:49
|
> 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. 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? > statement in the Makefile.PL and Tcl.pm to document this. Probably > also say so in the README. "Changes" file of Tcl distribution claims compatibility with 5.005 in 0.7 Best regards, Vadim. |
From: Gisle A. <gi...@Ac...> - 2004-04-14 09:41:20
|
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); } } } |
From: Gisle A. <gi...@Ac...> - 2004-04-14 09:26:22
|
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); Why is Tcl as subclass of Tck::Tk insted of the other way around? The other way seems more logical. --Gisle |
From: Gisle A. <gi...@Ac...> - 2004-04-14 09:21:57
|
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; statement in the Makefile.PL and Tcl.pm to document this. Probably also say so in the README. --Gisle |
From: Gisle A. <gi...@Ac...> - 2004-04-14 09:12:45
|
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); |
From: Konovalov, V. <vko...@sp...> - 2004-04-14 09:01:53
|
> The Tcl and Tcl-Tk package both come with a file called > 'ceMakefile.pl'. This will get installed on 'make install' as all > *.pl are. > > I suggest you rename it as 'ceMakefile.PL' or just make sure that the > standard Makefile.PL can support WinCE. Indeed. Thanks, will try solving this problem at next release. Best regards, Vadim. |
From: Gisle A. <gi...@Ac...> - 2004-04-14 08:57:05
|
The Tcl and Tcl-Tk package both come with a file called 'ceMakefile.pl'. This will get installed on 'make install' as all *.pl are. I suggest you rename it as 'ceMakefile.PL' or just make sure that the standard Makefile.PL can support WinCE. --Gisle |
From: Konovalov, V. <vko...@sp...> - 2004-04-14 06:14:14
|
Dear Jeff, 1. Right now there exist widgets (like Button, Label and so on) that when created live in their own package, say, Tcl::Tk::Widget::Button This will help in not interfering methods between widgets. Works better than I expected. (I thought doing this will be more complicated than it actually became) However complicated widgets behave differently, say, "Menu" becomes Tcl::Tk::Widget and not Tcl::Tk::Widget::Menu. I am going to fix this, probably before releasing to CPAN. Do you have additional ideas on this? 2. It is actually not clear to me why most code in "need_tk" must present there, and therefore much of TODO there. I mean why I code like $int->Eval("destroy [tixTree .___ptk_tree]"); #TODO must be there. Do you have an idea why calling $int->call("tixTree", ...) is not good enough to find proper name? Something with TCL autoloading? (BTW tk_optionMenu behaves same way) 3. Is it good to create some support "tcl" or "tk" files inside Tcl-Tk just to ease processing? Create some Tcl/Tk wrappers to move some logic from Tcl::Tk to nearby files 4. I think it would be very nice in addition to existing perlTk compatibility widgets to create a while bunch of new widgets with same logic, and this will create some more interest of using module. Best regards, Vadim. |
From: Konovalov, V. <vko...@sp...> - 2004-04-13 10:22:37
|
> [[I am switching context on this message from tcltkce-user to > the newly created tcltk-perl. Drop tcltkce-user after this > for Perl/Tcl::Tk related discussion]]. ok > 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) > > First off, what's wrong with tk_optionMenu? I think anything I just didn't knew that. Thanks for pointing out, I'll remove both Tix and itk implementations, and will try tk_optionMenu. > that that very simple pseudo-widget doesn't handle should be > done with a Combobox instead. In that case, I would > recommend more use of BWidget widgets over Tix of iwidgets. > It's pure Tcl, thus much more portable (eg, to Win/CE). That > can be a disadvantage for it's Tree when you have 10,000 > elements, but for most widgets isn't an issue. 10,000 is not a number that is likely to be processed in Optionmenu in any way. OTOH it's hard for me to beleive Tix is able to easily process 10,000 items. Am I wrong? > > 3. > > When writing test suite, a module must know whether Tix or > > BWidget are available and do not run test suite that has no > > TCL support. Besides, do you have an idea how to let people > > know about their TCL installation? I mean showing some kind > > of nice colorful table that shows available capabilities in > > TCL installation... > > > > something like > > perl -MTcl::Tk -V > > to show configuration information... > > Some of that info is in the related tcl|tkConfig.sh that I > allow us to reference in the updated Makefile.PLs. A lot more > info is available dynamically with 'package names' and the like. thanks, I'll look into this. > > I think it would be rather clever to define some commands from > Perl into the Tcl interp that allow for callbacks into perl, > like > set res [perl::eval <perl_code_here>] > and the like. That would allow more capable introspection in > both directions, and allow for using consoles like tkcon to > really shine in the Perl/Tcl::Tk environment. This is one of my dreams... :) It would be lovely to have such a possibility. Best regards, Vadim. |
From: Jeff H. <je...@Ac...> - 2004-04-12 23:48:11
|
[[I am switching context on this message from tcltkce-user to the newly created tcltk-perl. Drop tcltkce-user after this for Perl/Tcl::Tk related discussion]]. > From: Eruhim Watman > 1. > I was playing with "Optionmenu" and implemented many options using two > ways: Tix's OptionMenu and itk's iwidget::Optionmenu. I do > not know what to prefer. Neither. I'm trying to move away from dependence on anything in Tix. Although I recently completely rewrote its build system to be more modern, the whole design just isn't that useful anymore. I also dislike iwidgets for its bloat, but it is included in ActiveTcl, so is "ok" in some sense. 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. First off, what's wrong with tk_optionMenu? I think anything that that very simple pseudo-widget doesn't handle should be done with a Combobox instead. In that case, I would recommend more use of BWidget widgets over Tix of iwidgets. It's pure Tcl, thus much more portable (eg, to Win/CE). That can be a disadvantage for it's Tree when you have 10,000 elements, but for most widgets isn't an issue. > 2. sub need_tk: I hope you do not mind if we'll call it > recursively? I mean when "Combobox" requires "BWidget" and we > could just call > need_tk("BWidget") and do not add complications by checking > hash entry for $preloaded_tk{"BWidget"} or > $preloaded_tk{"Tix"} each time... I don't mind, I just add those bits without much thought. > 3. > When writing test suite, a module must know whether Tix or > BWidget are available and do not run test suite that has no > TCL support. Besides, do you have an idea how to let people > know about their TCL installation? I mean showing some kind > of nice colorful table that shows available capabilities in > TCL installation... > > something like > perl -MTcl::Tk -V > to show configuration information... Some of that info is in the related tcl|tkConfig.sh that I allow us to reference in the updated Makefile.PLs. A lot more info is available dynamically with 'package names' and the like. I think it would be rather clever to define some commands from Perl into the Tcl interp that allow for callbacks into perl, like set res [perl::eval <perl_code_here>] and the like. That would allow more capable introspection in both directions, and allow for using consoles like tkcon to really shine in the Perl/Tcl::Tk environment. Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos |