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

[tcltk-perl] Patch to build tcl-perl against Tcl.framework on Mac OS X

[Daniel A. S. <st...@ic...>]

All,

attached a patch to get the Tcl perl module to build against 
Tcl.framework on Mac OS X (with --tclconfig 
/Library/Frameworks/Tcl.framework/tclConfig.sh), both with and without 
stubs.

Tcl::Tk will have to wait until [package require Tk] works with 
TkAqua...

Cheers,

Daniel

-- 
** Daniel A. Steffen     **  "And now for something completely
** Dept. of Mathematics  **   different"    Monty Python
** Macquarie University  **  <mailto:st...@ma...>
** NSW 2109 Australia    **  <http://www.maths.mq.edu.au/~steffen/>


Index: Makefile.PL
===================================================================
RCS file: /cvsroot/tcltkce/Tcl/Makefile.PL,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile.PL
--- Makefile.PL	8 May 2004 02:11:12 -0000	1.9
+++ Makefile.PL	11 Aug 2004 14:43:24 -0000
@@ -16,6 +16,7 @@ my $usestubs;
  my $libpath;
  my $incpath;
  my $wince;
+my @extraargs;

  GetOptions("tclsh=s", \$tclsh,
  	   "tclconfig=s", \$tclconfig,
@@ -80,10 +81,17 @@ if ($tclconfig) {
  	if ($^O eq 'MSWin32') {
  	    $defs .= " 
-DLIB_RUNTIME_DIR=\\\"$tclcfg{'TCL_EXEC_PREFIX'}/bin\\\"";
  	    $defs .= " -DTCL_LIB_FILE=\\\"$tclcfg{'TCL_DLL_FILE'}\\\"";
+	} elsif ($^O eq 'darwin' && $tclcfg{'TCL_STUB_LIB_PATH'} =~ 
/\.framework/ ) {
+	    (my $fmk = $tclcfg{'TCL_STUB_LIB_PATH'}) =~ 
s/(?<=\.framework).*//;
+	    $defs .= " -DLIB_RUNTIME_DIR=\\\"$fmk\\\"";
+	    $defs .= " -DTCL_LIB_FILE=\\\"$tclcfg{'TCL_LIB_FILE'}\\\"";
  	} else {
  	    $defs .= " 
-DLIB_RUNTIME_DIR=\\\"$tclcfg{'TCL_EXEC_PREFIX'}/lib\\\"";
  	    $defs .= " -DTCL_LIB_FILE=\\\"$tclcfg{'TCL_LIB_FILE'}\\\"";
  	}
+    } elsif ($^O eq 'darwin' && $libpath =~ /-framework/ ) {
+	@extraargs = (dynamic_lib => {OTHERLDFLAGS => $libpath});
+	$libpath = "";
      }
  } else {
      open(TCLSH, "$tclsh tclcfg.tcl |") or die "error starting tclsh: 
$!\n";
@@ -138,6 +146,7 @@ WriteMakefile(
      LIBS => ["$libpath"],
      INC => "$incpath",
      DEFINE => $defs,
+    @extraargs,
  );

  #EOS

[tcltk-perl] RE: [Tcltkce-user] some plans

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

> > Yet I'll remove sub DEBUG {} from Tcl::Tk completely and 
> will hopefully move
> > Tcl::Tk closer to 1.0 release.
> > 
> 
> Does a more complete Perl/Tk compatibility layer belong to the goals
> for a 1.0 release? I never tried it, but I suspect that the Perl/Tk
> mega widget support won't work with Tcl::Tk.

Perl/Tk mega widget will probably not work.

Actually I had an ideas about implemented this using Tix megawidget support
(because Perl/Tk megawidgets rely on Tix).
I tried to think about this but gone not far enough to get some real ideas.

Implementing source code compatibility for Perl/Tk megawidgets will result
in growing otherwise very small module.
It is possible to move such supoprt to separate module.
(side note: there were ideas in this list about moving Tcl::Tk to Tcl Perl
module)

Yet I do understand lack of pure-Perl megawidgets is not good, there must
exist a way to create pure-Perl widgets, even not compatible with Perl/Tk.
Tcl::Tk::Widget::MultipleWidget provides something for this, and may be this
approach will be as replacement.

Most realistic plans to the moment is to create a number of Tcl::Tk
sub-modules to reimplement some existing Perl/Tk widgets to provide same
functionality for Tcl::Tk.

Best regards,
Vadim.

[tcltk-perl] Re: [Tcltkce-user] some plans

[Slaven R. <sl...@re...>]

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

> Dear all, dear Jeff!
> 
[...]
> 
> Yet I'll remove sub DEBUG {} from Tcl::Tk completely and will hopefully move
> Tcl::Tk closer to 1.0 release.
> 

Does a more complete Perl/Tk compatibility layer belong to the goals
for a 1.0 release? I never tried it, but I suspect that the Perl/Tk
mega widget support won't work with Tcl::Tk.

Regards,
        Slaven

-- 
Slaven Rezic - sl...@re...

    tkrevdiff - graphical display of diffs between revisions (RCS, CVS or SVN)
    http://ptktools.sourceforge.net/#tkrevdiff

[tcltk-perl] some plans

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

Dear all, dear Jeff!

I am going to develop a bit on both perlce and tcltkce SF projects, and,
most importantly, will try to explain on http://tcltkce.sf.net about
collaboration of the two with usage of Tcl::Tk module, and all this stuff
happening on WinCE.

There are some problems that make things a bit harder:
 - on tcltkce, radiobutton looks like checkbutton and vice versa. Both
behave correctly though.
 - menu is not shown. When I tried to fix (I changed tk.rc file to have
resource 123 to be main menu, like VimCE do), after fixing tcltk hangs when
using menu and do not hangs until I use them.

Previously I thought those problems are only configuration problems with my
MIPS (cassiopeia E-125) but I tried ready binaries for ARM processor with
PocketPC-2003 and saw exactly same results.

I am ready to spend some efforts fixing this
But I really afraid I will either not succeed at all or spend too much
effort on this.
Or may be even combination of the two.

Could you please advice a bit on this? Confirm or deny my experience?

Which way should I follow in order to fix? 
Jeff? Please?

Nearest weekend is when I do start and will progress during most of next
week so will probably show results after first or second weekend of June.

Yet I'll remove sub DEBUG {} from Tcl::Tk completely and will hopefully move
Tcl::Tk closer to 1.0 release.

More advices/comments?

Best regards,
Vadim.

[tcltk-perl] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

RE: [tcltk-perl] info hostname discrepancy

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

> > We get consistent test failures on some machines in t/info.t on:
> > 
> > ok($tcl->Eval("info hostname"), hostname);
> > 
> > where one side returns the 'machine' and the other 
> > 'machine.domain.com'.  Is there a real reason to even have this test 
> > in there?  I can understand the 'info nameofexecutable' check, but 
> > hostname seems irrelevant for testing the bridge.
> 
> I added this code at some point.  I just had to test 
> something info related, and this just try to check if Tcl and 
> Perl manage to agree on what the hostname is.  Apparently 
> they don't.  Who is wrong?

I think they do agree on the hostname - they just disagree on
what "hostname" really means - for Tcl it is fully qualified
(with domainname) and for Perl it's just the name, although Tcl
does doc to say that it's not guaranteed to be the fully
qualified one (it depends on TCP/IP setup).  I think its fair
to say they are just different, and if we want to keep it, just
compare up to the first '.' only.

> I'm certainly ok with just removing this test.

and that's of course the easiest.

Jeff

Re: [tcltk-perl] info hostname discrepancy

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

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

> We get consistent test failures on some machines in t/info.t on:
> 
> ok($tcl->Eval("info hostname"), hostname);
> 
> where one side returns the 'machine' and the other 'machine.domain.com'.  Is
> there a real reason to even have this test in there?  I can understand the
> 'info nameofexecutable' check, but hostname seems irrelevant for testing the
> bridge.

I added this code at some point.  I just had to test something info
related, and this just try to check if Tcl and Perl manage to agree on
what the hostname is.  Apparently they don't.  Who is wrong?

I'm certainly ok with just removing this test.

--Gisle

[tcltk-perl] info hostname discrepancy

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

We get consistent test failures on some machines in t/info.t on:

ok($tcl->Eval("info hostname"), hostname);

where one side returns the 'machine' and the other 'machine.domain.com'.  Is
there a real reason to even have this test in there?  I can understand the
'info nameofexecutable' check, but hostname seems irrelevant for testing the
bridge.

Jeff

Re: [tcltk-perl] CPAN release, version 0.80

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

> > Still, I do not know how to make for CPAN indexer not to check for files
in
> > tk-demos and demos directories
> >
> > Does anyone has a cure to the problem?

fortunately problem was fixed, and it was syntax error in YAML format,
namely number of spaces at the start of some lines.

>
> I'm not sure if the CPAN indexer implements this too, but for
search.cpan.org
> to ignore a module, you have to list it in the private: section of a
META.yml
> file.

'private' works fine.

Best regards,
Vadim.

[tcltk-perl] Re: FAIL Tcl-Tk-0.81 ppc-linux 2.4.19-4a

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

All errors below are due to Tcl/Tk installation to be not fully
complete. Tour Tcl/Tk installation can not find Tk package from within
tclsh.

Namely, inside that installation directory .../tk8.4/ should contain a
file named 'pkgIndex.tcl'

If you'll feed "package require Tk" to "tclsh" you'll see this error.

We did not fully decided on what solution must be - either just warn
user in Makefile.PL and refuse to go forward, or trying to mimic that
file during procesing...



CTCa> Below is the error stack during 'make test':

CTCa> PERL_DL_NONLAZY=1 /usr/local/perl-5.8.4/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
CTCa> t/after.........can't find package Tk at /home/alian/.cpanplus/5.8.4/build/Tcl-Tk-0.81/blib/lib/Tcl/Tk.pm line 704.
CTCa> dubious
CTCa>         Test returned status 255 (wstat 65280, 0xff00)
CTCa> DIED. FAILED tests 1-6
CTCa>         Failed 6/6 tests, 0.00% okay
CTCa> t/geomgr........can't find package Tk at /home/alian/.cpanplus/5.8.4/build/Tcl-Tk-0.81/blib/lib/Tcl/Tk.pm line 704.
CTCa> dubious
CTCa>         Test returned status 255 (wstat 65280, 0xff00)
CTCa> DIED. FAILED tests 1-14
CTCa>         Failed 14/14 tests, 0.00% okay
CTCa> t/optmenu.......# Test 1 got: 'can't find package Tk at /home/alian/.cpanplus/5.8.4/build/Tcl-Tk-0.81/blib/lib/Tcl/Tk.pm line 704.
CTCa> ' (t/optmenu.t at line 15)
CTCa> #   Expected: '' (can't create MainWindow)
CTCa> #  t/optmenu.t line 15 is: ok($@, "", "can't create MainWindow");
CTCa> # Test 2 got: '0' (t/optmenu.t at line 16)
CTCa> #   Expected: '1' (MainWindow creation failed)
CTCa> #  t/optmenu.t line 16 is: ok(Tcl::Tk::Exists($mw), 1, "MainWindow creation failed");
CTCa> Can't call method "Optionmenu" on an undefined value at t/optmenu.t line 22.
CTCa> dubious
CTCa>         Test returned status 255 (wstat 65280, 0xff00)
CTCa> DIED. FAILED tests 1-20
CTCa>         Failed 20/20 tests, 0.00% okay
CTCa> t/photo.........can't find package Tk at /home/alian/.cpanplus/5.8.4/build/Tcl-Tk-0.81/blib/lib/Tcl/Tk.pm line 704.
CTCa> dubious
CTCa>         Test returned status 255 (wstat 65280, 0xff00)
CTCa> t/ptk-compat....# Test 1 got: 'can't find package Tk at /home/alian/.cpanplus/5.8.4/build/Tcl-Tk-0.81/blib/lib/Tcl/Tk.pm line 704.
CTCa> ' (t/ptk-compat.t at line 15)
CTCa> #   Expected: '' (can't create MainWindow)
CTCa> #  t/ptk-compat.t line 15 is: ok($@, "", "can't create MainWindow");
CTCa> # Test 2 got: '0' (t/ptk-compat.t at line 16)
CTCa> #   Expected: '1' (MainWindow creation failed)
CTCa> #  t/ptk-compat.t line 16 is: ok(Tcl::Tk::Exists($mw), 1, "MainWindow creation failed");
CTCa> Can't call method "Frame" on an undefined value at t/ptk-compat.t line 19.
CTCa> dubious
CTCa>         Test returned status 255 (wstat 65280, 0xff00)
CTCa> DIED. FAILED tests 1-5
CTCa>         Failed 5/5 tests, 0.00% okay
CTCa> t/text..........can't find package Tk at /home/alian/.cpanplus/5.8.4/build/Tcl-Tk-0.81/blib/lib/Tcl/Tk.pm line 704.
CTCa> dubious
CTCa>         Test returned status 255 (wstat 65280, 0xff00)
CTCa> DIED. FAILED test 1
CTCa>         Failed 1/1 tests, 0.00% okay
CTCa> t/zzPhoto.......can't find package Tk at /home/alian/.cpanplus/5.8.4/build/Tcl-Tk-0.81/blib/lib/Tcl/Tk.pm line 704.
CTCa> dubious
CTCa>         Test returned status 255 (wstat 65280, 0xff00)
CTCa> DIED. FAILED tests 1-13
CTCa>         Failed 13/13 tests, 0.00% okay
CTCa> Failed Test    Stat Wstat Total Fail  Failed  List of Failed
CTCa> -------------------------------------------------------------------------------
CTCa> t/after.t       255 65280     6   12 200.00%  1-6
CTCa> t/geomgr.t      255 65280    14   28 200.00%  1-14
CTCa> t/optmenu.t     255 65280    20   38 190.00%  1-20
CTCa> t/photo.t       255 65280    ??   ??       %  ??
CTCa> t/ptk-compat.t  255 65280     5    8 160.00%  1-5
CTCa> t/text.t        255 65280     1    2 200.00%  1
CTCa> t/zzPhoto.t     255 65280    13   26 200.00%  1-13
CTCa> Failed 7/7 test scripts, 0.00% okay. 59/59 subtests failed, 0.00% okay.
CTCa> make: *** [test_dynamic] Error 2


CTCa> Additional comments:
CTCa> --

CTCa> Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
CTCa>   Platform:
CTCa>     osname=linux, osvers=2.4.19-4a, archname=ppc-linux
CTCa>     uname='linux triton.alianet 2.4.19-4a #1 wed jun 5 01:34:59 edt 2002 ppc unknown '
CTCa>     config_args='-des -Dprefix=/usr/local/perl-5.8.4/'
CTCa>     hint=recommended, useposix=true, d_sigaction=define
CTCa>     usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
CTCa>     useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
CTCa>     use64bitint=undef use64bitall=undef uselongdouble=undef
CTCa>     usemymalloc=n, bincompat5005=undef
CTCa>   Compiler:
CTCa>     cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
CTCa>     optimize='-O1',
CTCa>     cppflags='-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
CTCa>     ccversion='', gccversion='2.95.4 20010319 (prerelease/franzo/20011204)', gccosandvers=''
CTCa>     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
CTCa>     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
CTCa>     ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
CTCa>     alignbytes=8, prototype=define
CTCa>   Linker and Libraries:
CTCa>     ld='cc', ldflags =' -L/usr/local/lib'
CTCa>     libpth=/usr/local/lib /lib /usr/lib
CTCa>     libs=-lnsl -lndbm -lgdbm -ldl -lm -lcrypt -lutil -lc
CTCa>     perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
CTCa>     libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a
CTCa>     gnulibc_version='2.2.5'
CTCa>   Dynamic Linking:
CTCa>     dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
CTCa>     cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'



-- 
Best regards,
 Vadim                            mailto:vko...@pe...

[tcltk-perl] CPAN release 0.81

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

I did another CPAN release,

one thing that bothers me in Tcl::Tk is a DEBUG subroutine that really have
complicated logic. Actually it make my debugging harder :)

Actually it must be
sub DEBUG () {
  1; # or 0
}

This way in release mode Perl optimizer will throw away any construct like
if(DEBUG) {
 ....
}

Please either remove it or made it constant subroutine.

Besides, now debugging becomes more complicated because of overloading....

Best regards,
Vadim.

Re: [tcltk-perl] recent additions to Tcl::Tk

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

> Right now I'll try to make it respect more than one interpreter.

ok, I finished those changes, now %W based on window id.

Hopefully things should be better.

Vadim.

[tcltk-perl] I've added new developer

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

Dear all,

just now I've added Slaven Rezic to developers of tcltkce project to provide
a possibility for Slaven to make CVS comits directly.

Slaven is perlTk expert and sent me some patches, and I think most of them
should go directly to repository.

Best regards,
Vadim.

[tcltk-perl] recent additions to Tcl::Tk

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

Dear all,

I did quite principal change to rework %W package hash.

As I mentioned earlier, $W{$$path}->{'INT'} was something that should be
changed, and (as I think) we agreed to either remove that or make this
better.

Previously %W was a hash to hold a number of tiny anonymous hashes with keys
INT and PATH, and now it is reversed: it contains three large anonymos
subhashes. This will save resources, IMHO.

Right now I'll try to make it respect more than one interpreter.

Best regards,
Vadim.

[tcltk-perl] overload stringification of widgets

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

As you may have noticed, I did a change to make for any widget to be its
path when stringification occurs.
so
perl -MTcl::Tk -we "$i =Tcl::Tk::tkinit->Button->pack; print $i"
outputs
.btn01


Interesting to say, it required adding just one line to Tk.pm:

  use overload '""' => \&path;

Now code from tk-demo like
    my $f_list = $f->Listbox;
    my $f_scroll = $f->Scrollbar(-command => [$f_list => 'yview']);

works via stringification of $f_list.

However, I wonder if there will be any consequences (I mean slowdown).
If anyone notices this, please speak.

Using "Benchmark.pm" Perl module:
I commented line "MainLoop" in 'wdiget' from 'tk-demo' directory, and here
it is:

w/o overload:
>perl -MBenchmark -e "timethis 100, sub{do 'widget0'}"
timethis 100:  6 wallclock secs ( 5.28 usr +  0.59 sys =  5.87 CPU) @
17.04/s (n=100)
>perl -MBenchmark -e "timethis 300, sub{do 'widget0'}"
timethis 300: 17 wallclock secs (15.12 usr +  1.27 sys = 16.39 CPU) @
18.30/s (n=300)

w/ overload:
>perl -MBenchmark -e "timethis 100, sub{do 'widget0'}"
timethis 100:  6 wallclock secs ( 5.38 usr +  0.56 sys =  5.94 CPU) @
16.84/s (n=100)
>perl -MBenchmark -e "timethis 300, sub{do 'widget0'}"
timethis 300: 16 wallclock secs (15.19 usr +  1.19 sys = 16.38 CPU) @
18.31/s (n=300)

Now same with perlTk:
widget0-ptk is 'widget' from distribution perlTk804-024, with three lines
commented out:
#use lib Tk->findINC('demos/widget_lib');
...
#use WidgetDemo;
...
#MainLoop;

perl -MBenchmark -e "timethis 100, sub{do 'widget0-ptk'}"
timethis 100: 19 wallclock secs (17.70 usr +  1.41 sys = 19.11 CPU) @
5.23/s (n=100)
300:
timethis 300: 57 wallclock secs (51.57 usr +  4.61 sys = 56.18 CPU) @
5.34/s (n=300)

Best regards,
Vadim.

RE: [tcltk-perl] RE: Re[2]: FAIL Tcl-Tk-0.80 i686-linux 2.4.18-14

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

> > In any case, I'd like to encourage use of 8.4 instead, and perhaps add 
> > some warnings to that effect in Makefile.PL.  Hmmm,
> 
> Encouraging is good, but IMHO even more good making tool 
> working even with old stuff, without downloading new updates. 
> Yat I agree that supporting old versions is low priority task 
> and supporting obsolete versions is not necessary.

If they want to work with Tcl 8.3, they can use the pre-0.77 Tcl
module.  We are doing current development, and the current Tcl
release is Tcl 8.4 (has been the stable for a couple years now).

> > Soooo ... I'll probably be putting in code in the Makefile.PL and 
> > runtime stuff to force the use of 8.4.  That's actually the case
> 
> Makefile.PL should deny all configurations that not 
> supported, otherwise there will be FAIL's reports. Even not 
> warnings, just strictly denying to go further.

I have the Makefile.PL patches ready to accomodate this (throw
errors, not warnings, for any attempt to build against pre-8.4
versions of Tcl).

Jeff

Re: [tcltk-perl] RE: Re[2]: FAIL Tcl-Tk-0.80 i686-linux 2.4.18-14

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

> In any case, I'd like to encourage use of 8.4 instead, and
> perhaps add some warnings to that effect in Makefile.PL.  Hmmm,

Encouraging is good, but IMHO even more good making tool working even with
old stuff, without downloading new updates.
Yat I agree that supporting old versions is low priority task and supporting
obsolete versions is not necessary.


> Soooo ... I'll probably be putting in code in the Makefile.PL and
> runtime stuff to force the use of 8.4.  That's actually the case

Makefile.PL should deny all configurations that not supported, otherwise
there will be FAIL's reports.
Even not warnings, just strictly denying to go further.

Best regards,
Vadim.

[tcltk-perl] RE: Re[2]: FAIL Tcl-Tk-0.80 i686-linux 2.4.18-14

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

> SR> This is on a RedHat 8.0 machine with the default Tcl and Tk (both 
> SR> version 8.3) installed from RPM:

IMO RedHat is a fairly crappy distro that has a poor package
maintenance record in places (in fact, they totally screwed up
things in RH9 for Tcl and Python by making incorrect core changes
without first contacting either core team - which are always
active and responsive).  RH9 was worse than 8, and Fedora just
isn't improving their record.  So that's my rant ...

That said, 8.3 didn't get "proper" support for Tk as a full
loadable package until 8.3.4 IIRC (release 2001).  I know that
all distros didn't add a pkgIndex.tcl file to Tk though, so you
might just need to add that.

In any case, I'd like to encourage use of 8.4 instead, and
perhaps add some warnings to that effect in Makefile.PL.  Hmmm,
on second thought, I want to *force* 8.4, as I am using several
8.4-isms in the Tk.pm code anyway.  It's been the stable release
since 2002 and is definitely in good shape now.  It also allows
some fancy stuff - just yesterday I got dll-based base kits
working.  This means all of Tcl/Tk + extensions can be housed in
a single dll (.so, whatever) that you use for your apps.

Soooo ... I'll probably be putting in code in the Makefile.PL and
runtime stuff to force the use of 8.4.  That's actually the case
to do things right anyway, I just didn't force it in the build
yet.  Using stubs (--usestubs), you can actually build against
8.3 and run properly against 8.4, but we should just force the
8.4 issue as early as possible (no surprises).

The easiest thing to do when 8.4 isn't the default on your path
(otherwise you shouldn't need to do) is to use the --tclsh or
--tclconfig options to the Tcl Makefile.PL.

Jeff

Re: [tcltk-perl] Re: Re[2]: FAIL Tcl-Tk-0.80 i686-linux 2.4.18-14

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

> > SR> This is on a RedHat 8.0 machine with the default Tcl and Tk (both
> > SR> version 8.3) installed from RPM:
> >
> > SR> tclsh
> > SR> % package require Tk
> > SR> can't find package Tk
> > SR> %
> >
> > SR> wish
> > SR> % package require Tk
> > SR> 8.3
> > SR> %
> >
> > This exactly means your tcl misses some autoloading support.
> >
> > There must exist a file /usr/local/lib/tk8.3/pkgIndex.tcl
> >
> > It has following contents on my cygwin system:
> > if {[package vcompare [package provide Tcl] 8.4] != 0} { return }
> > package ifneeded Tk 8.4 [list load [file join $dir .. .. bin tk84.dll]
Tk]
>
> locate pkgIndex.tcl returns the following list (excluding private and
> source directories):
>
> /usr/lib/tcl8.3/http1.0/pkgIndex.tcl
> /usr/lib/tcl8.3/http2.3/pkgIndex.tcl
> /usr/lib/tcl8.3/msgcat1.1/pkgIndex.tcl
> /usr/lib/tcl8.3/opt0.4/pkgIndex.tcl
> /usr/lib/tcl8.3/tcltest1.0/pkgIndex.tcl

See? That file do not exists

> /usr/local/lib/tcl8.4/http2.4/pkgIndex.tcl
> /usr/local/lib/tcl8.4/http1.0/pkgIndex.tcl
> /usr/local/lib/tcl8.4/opt0.4/pkgIndex.tcl
> /usr/local/lib/tcl8.4/msgcat1.3/pkgIndex.tcl
> /usr/local/lib/tcl8.4/tcltest2.2/pkgIndex.tcl
> /usr/local/lib/tk8.4/pkgIndex.tcl

See? Your tk8.4 is better, if you'll try it, you'll probably get better
results.


> /usr/local/lib/Tkzinc3.2.94/pkgIndex.tcl
>
> The /usr/lib bits are from the standard RedHat install, and the
> /usr/local/lib ones are from my own install, but this version is
> apparently not used.

Ok, to support standard RedHat 8.0 without extra recompilation we need to
work around this error.
Besides, AFAIK RedHat distribution comes without perlTk, so Tcl::Tk could be
desried there more than usual...

Asking  from tcl...@li... , how do we decide to do?

Best regards,
Vadim.

[tcltk-perl] Re: Re[2]: FAIL Tcl-Tk-0.80 i686-linux 2.4.18-14

[Slaven R. <sr...@ic...>]

On Fri, 2004-05-07 at 13:43, Vadim Konovalov wrote:
> SR> This is on a RedHat 8.0 machine with the default Tcl and Tk (both
> SR> version 8.3) installed from RPM:
> 
> SR> tclsh
> SR> % package require Tk
> SR> can't find package Tk
> SR> %
> 
> SR> wish
> SR> % package require Tk
> SR> 8.3
> SR> %
> 
> This exactly means your tcl misses some autoloading support.
> 
> There must exist a file /usr/local/lib/tk8.3/pkgIndex.tcl
> 
> It has following contents on my cygwin system:
> if {[package vcompare [package provide Tcl] 8.4] != 0} { return }
> package ifneeded Tk 8.4 [list load [file join $dir .. .. bin tk84.dll] Tk]
> 
> Yours will differ.

locate pkgIndex.tcl returns the following list (excluding private and
source directories):

/usr/lib/tcl8.3/http1.0/pkgIndex.tcl
/usr/lib/tcl8.3/http2.3/pkgIndex.tcl
/usr/lib/tcl8.3/msgcat1.1/pkgIndex.tcl
/usr/lib/tcl8.3/opt0.4/pkgIndex.tcl
/usr/lib/tcl8.3/tcltest1.0/pkgIndex.tcl
/usr/local/lib/tcl8.4/http2.4/pkgIndex.tcl
/usr/local/lib/tcl8.4/http1.0/pkgIndex.tcl
/usr/local/lib/tcl8.4/opt0.4/pkgIndex.tcl
/usr/local/lib/tcl8.4/msgcat1.3/pkgIndex.tcl
/usr/local/lib/tcl8.4/tcltest2.2/pkgIndex.tcl
/usr/local/lib/tk8.4/pkgIndex.tcl
/usr/local/lib/Tkzinc3.2.94/pkgIndex.tcl

The /usr/lib bits are from the standard RedHat install, and the
/usr/local/lib ones are from my own install, but this version is
apparently not used.

Regards,
    Slaven

> However this either means RedHat distribution lacks something, or we
> must perform required actions in Makefile.PL
> 
> I hope Tcl/Tk experts will give an advice?
> (Jeff, could you please advice?)
> 
> Best regards,
> Vadim.
> 
-- 
Slaven Rezic > Development

iconmobile GmbH > Methfesselstr. 32-36 > D-10965 Berlin
phone +49 30 890 686 49 > fax +49 30 890 686 50
sr...@ic... > http://www.iconmobile.com

[tcltk-perl] Re[2]: FAIL Tcl-Tk-0.80 i686-linux 2.4.18-14

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

SR> This is on a RedHat 8.0 machine with the default Tcl and Tk (both
SR> version 8.3) installed from RPM:

SR> tclsh
SR> % package require Tk
SR> can't find package Tk
SR> %

SR> wish
SR> % package require Tk
SR> 8.3
SR> %

This exactly means your tcl misses some autoloading support.

There must exist a file /usr/local/lib/tk8.3/pkgIndex.tcl

It has following contents on my cygwin system:
if {[package vcompare [package provide Tcl] 8.4] != 0} { return }
package ifneeded Tk 8.4 [list load [file join $dir .. .. bin tk84.dll] Tk]

Yours will differ.

However this either means RedHat distribution lacks something, or we
must perform required actions in Makefile.PL

I hope Tcl/Tk experts will give an advice?
(Jeff, could you please advice?)

Best regards,
Vadim.

[tcltk-perl] web explanations to observe

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

Dear all,

I did some web explanations:
http://www.vkonovalov.ru/vtcl-usage/Using_vtcl_for_creating_Tcl-Tk_GUI_for_P
erl.html

and it is linked from
http://perlmonks.com/index.pl?node_id=351324


I do not fully sure how to do things better, and will be extremely glad for
any help from knowledgable people.

If nothing will stop me, now I'll go to Tcl::Tk/tk-demos/ directory and
continue cleaning things there...

Best regards,
Vadim.

Re: [tcltk-perl] changes to Tcl and Tcl::Tk

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

> > I guess I'm asking "What would be the difference between these?".

I forgot to mention last time -- need_tk also checks for some package to be
required only *once*, and this is quite important to not make same thing
second time.

> >    $tcl->call("package", "require", $pkg);
> >    $tcl->pkg_require($pkg);
> >
>
> It has special knowledge how to obtain something, for example, widgets
that
> implemented with "Tix" will require Tix recursively

RE: [tcltk-perl] changes to Tcl and Tcl::Tk

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

> > I implemented the changes to Tcl so that Tcl::icall now uses Tcl's 
> > unknown (AUTOLOAD) mechanism properly and kept the old version as 
> > Tcl::invoke (not directly used anywhere).
> 
> And you documented this properly... Very nice.
> 
> Do I understand this correctly that Tcl::invoke should be 
> used in simple cases to improve speed?

It would be interesting to see an icall/invoke comparison in
speed if someone wanted to make it.  invoke should be a smidge
faster, but I wouldn't recommend it in general because of the
caveats of usage - the command must exist, and you circumvent
a lot of stuff like command tracing, recursion safety-checks,
and the unknown mechanism.

Jeff

Re: [tcltk-perl] changes to Tcl and Tcl::Tk

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

> Why this wrapper at all?  Why not call out to Tcl each time?
>
> I guess I'm asking "What would be the difference between these?".
>
>    $tcl->call("package", "require", $pkg);
>    $tcl->pkg_require($pkg);
>

It has special knowledge how to obtain something, for example, widgets that
implemented with "Tix" will require Tix recursively