tcltk-perl

RE: [tcltk-perl] Code for Tcl mainloop routines

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

> Consequently, after talking with Vadim, I added a few 
> routines to Tcl.xs, with 
> the corresponding documentation in Tcl.pm and a test named 
> t/mainloop.t. The 
> routines provided are DoOneEvent, CreateChannelHandler, 
> DeleteChannelHandler, 
> MakeFileHandler, CreateTimerHandler and DeleteTimerHandler.
> 
> From that point, I have a proposal and a question:
> 
> - the proposal: IntuiLab is willing to share that code under 
> the same license 
> terms as perl-Tcl. I have prepared a patch based on Tcl-0.87 
> that I can send 
> upon request.

Please do so.


> 
> - the question: our next step was to integrate perl-Tk with 
> that mainloop 
> (yes, I know. But our code relies on perl-Tk and we can't 
> change that easily). 
> And we discovered that perl-Tk and Tcl *cannot* be used at 
> the same time: they 
> implement functions with the same name that do different 
> things. Consequently, 

Please provide more details here.
Probably you mean that you cound not link both perl/Tk and Tcl/tk into one
single binary file (either DLL or exe or somesuch)

Otherwise all is possible: Perl is able to contain both Tk and Tcl::Tk, and
they even could run together in one application.

Following lines are toy and nothing usefull, but application starts and even
works (buttons give their responces, and all is good until it gets not good
:):) 

use strict;
use Tk;
use Tcl::Tk;

if (fork) {
  tkinit->Button(-text=>'text',-command=>sub {
    print STDERR "he-he, perl/Tk\n";
  })->pack->MainLoop;
}
else {
  Tcl::Tk::tkinit->Button(-text=>'text2',-command=>sub {
    print STDERR "he-he, Tcl::Tk\n";
  })->pack->interp->MainLoop;
}

Also, two different loops are here; however "right" coexistence should rely
on one single MainLoop'

> we have had to build our own versions of Tcl and perl-Tcl 
> with all identifiers 
> changed :-( Any suggestion for a better solution? We are 
> willing to share the 
> bridge code (implemented as a Tcl notifier), but in the 
> present circumstances 
> it is pretty useless to anyone outside us.

Of course your efforts on adding perl/Tk compatibility to Tcl::Tk would be
very appreciated. Please share your ideas, .

I, for one, not spending many efforts on improving perl/Tk compatibility
right now, because I realized that I can move entirely into Tcl::Tk module.

Best regards,
Vadim.

Re: [tcltk-perl] Code for Tcl mainloop routines

[Stephane C. <ch...@in...>]

>> And we discovered that perl-Tk and Tcl *cannot* be used at 
>> the same time: they 
>> implement functions with the same name that do different 
>> things. Consequently, 

> Please provide more details here.
> Probably you mean that you cound not link both perl/Tk and Tcl/tk
> into one single binary file (either DLL or exe or somesuch)

Basically that's what I meant, yes. And that's what I think happens 
dynamically when I do the following on my Linux box:


------------
use Tcl; # leads libtcl8.4.so to be loaded
use Tk; # leads misc .so files from perl-Tk to be loaded

$mw = new MainWindow;
Tk::MainLoop;
---------------

and the result is
Segmentation fault (core dumped)


When I investigated that and looked at the core file with gdb, I found that 
the segfault occurs in perl-Tk's CreateFrame just after calling 
Tcl_GetStringFromObj. This function exists in both perl-Tk (in one of its .so 
file, in Linux) and in libtcl8.4.so. Apparently, the dynamic loader chooses  
the latter whereas perl-Tk expected the former to be called. This results in 
an invalid char* pointer being returned; when it is dereferenced, the program 
crashes..

St.

Re: [tcltk-perl] Code for Tcl mainloop routines

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

> that's what I think happens 
>dynamically when I do the following on my Linux box:
>
>
>------------
>use Tcl; # leads libtcl8.4.so to be loaded
>use Tk; # leads misc .so files from perl-Tk to be loaded
>
>$mw = new MainWindow;
>Tk::MainLoop;
>---------------
>
>and the result is
>Segmentation fault (core dumped)
>  
>
Well, this very small code does not do segmentation fault on Windows, 
and indeed does segmentation fault on Linux.


>
>When I investigated that and looked at the core file with gdb, I found that 
>the segfault occurs in perl-Tk's CreateFrame just after calling 
>Tcl_GetStringFromObj. This function exists in both perl-Tk (in one of its .so 
>file, in Linux) and in libtcl8.4.so. Apparently, the dynamic loader chooses  
>the latter whereas perl-Tk expected the former to be called. This results in 
>an invalid char* pointer being returned; when it is dereferenced, the program 
>crashes..
>  
>
Well, thank you a lot for providing analyzis.

Actually I tried my code long time ago both on Windows and Linux, and it 
did not crashed. Now I think this is due to perl/Tk version, which 
probably was 800.024, that one without Unicode support.

In my opinion, this is perl/Tk's fault in a name clash.

I wonder, will static building of perlTk help to avoid segmentation fault?

I did different rebuilds of Perl, Tcl/Tk on Windows and very little on 
Linux.
I succeeded statically building into perl DLL entire Tcl/Tk.

I'll try moving my previous experience to Linux and will see what 
combination will work.

Best regards,
Vadim.

Re: [tcltk-perl] Code for Tcl mainloop routines

[<ch...@in...>]

> In my opinion, this is perl/Tk's fault in a name clash.

Same opinion. But I have the vague feeling that the name clash is part
of the trick in perl-Tk: have Tk run over a fake Tcl library that relies
on Perl internals.

St.

Re: [tcltk-perl] Code for Tcl mainloop routines

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

Stephane Chatty wrote:
>>In my opinion, this is perl/Tk's fault in a name clash.
> 
> 
> Same opinion. But I have the vague feeling that the name clash is part
> of the trick in perl-Tk: have Tk run over a fake Tcl library that relies
> on Perl internals.

Yes, this is almost certainly the problem.  I actually put
some code in to handle this, but I see that I made it only
trigger in debug mode (in Tk.pm):

if (DEBUG()) {
     # The gestapo throws warnings whenever Perl/Tk modules are 
requested.
     # It also hijacks such requests and returns an empty module in its 

     # place. 

     unshift @INC, \&tk_gestapo;
}

You can see the def'n later in Tk.pm, but it basically hijacks
'use Tk' and related requests.  Since there is a naming issue,
we should probably reinstate this as a default, and change
from warning to error if we aren't fully hijacking and
replacing the content (which actually, I think we can do).

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

RE: [tcltk-perl] Code for Tcl mainloop routines

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

> >>In my opinion, this is perl/Tk's fault in a name clash.

....

> Yes, this is almost certainly the problem.  I actually put
> some code in to handle this, but I see that I made it only
> trigger in debug mode (in Tk.pm):
> 
> if (DEBUG()) {
>      # The gestapo throws warnings whenever Perl/Tk modules are 
> requested.
>      # It also hijacks such requests and returns an empty 
> module in its 
> 
>      # place. 
> 
>      unshift @INC, \&tk_gestapo;
> }

With all the respect, this code is useful and able to help to develop
perl/Tk compatibility within Tcl::Tk, but have little to do with a
coexistance problem, when using both modules results in segmentation fault.

Stephane, as you said you have a patch for CPAN module named Tcl (and may be
Tcl::Tk?). Would you mind if we look at it?

Best regards,
Vadim.

RE: [tcltk-perl] Code for Tcl mainloop routines

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

Konovalov, Vadim wrote:
> > >>In my opinion, this is perl/Tk's fault in a name clash.

> > if (DEBUG()) {
> >      # The gestapo throws warnings whenever Perl/Tk modules are
> > requested.
> >      # It also hijacks such requests and returns an empty 
> > module in its 
> >      # place.
> > 
> >      unshift @INC, \&tk_gestapo;
> > }
> 
> With all the respect, this code is useful and able to help to 
> develop perl/Tk compatibility within Tcl::Tk, but have little 
> to do with a coexistance problem, when using both modules 
> results in segmentation fault.

Hmmm, I will disagree because if we see the coexistence as an
insurmountable bug, the above is a valid work-around.  The
question is whether it is possible to support Tcl.pm and
Perl/Tk loaded simultaneously.  If that's fundamentally not
in the cards (Stephane's option of renaming all the functions
is a bit extreme), then this at least prevents crashes, right?

Jeff

Re: [tcltk-perl] Code for Tcl mainloop routines

[Stephane C. <ch...@in...>]

> Stephane, as you said you have a patch for CPAN module named Tcl (and may be
> Tcl::Tk?). Would you mind if we look at it?

It's not what I would call a patch:
 1- we took the Tcl 8.4 sources and did a global replacement of all 
identifiers starting with TCL, Tcl, or tcl
 2- same in perl-Tcl after applying the patches I sent to you
 3- and then we started the work on having perl-Tk and its embedded "Tcl" 
library use the mainloop from our renamed Tcl.

What I said was that I was ready to share the code from step 3, but:
 - there is nothing valuable to share for steps 1 and 2, except some weird 
version of Tcl 8.4 with strange variable and procedure names.
 - and the code from step 3 is useless if you don't use that weird Tcl of ours.

Vadim, I will send you the code but expect to be disappointed :-)

St.