RE: Trying to use Tk 8.6
> On MacOS 10.13.6 I have Perl 5.28 installed in /opt/local/
> using MacPorts. This works well and no problems installing modules using
> `cpanm`. I installed ActiveState's v8.6 of Tcl which is saved to
> `/Library/Frameworks/Tcl.framework/Versions/8.6` and then installed Tkx. My
> problem is I don't know how to make Tkx use the v8.6 version of Tcl/Tk. Here
> is how I think I know that it is not.
>
> $ perl -MTkx -e 'print Tkx::info("patchlevel");'
> 8.5.9
IMO this is because activestate ppm for Tkx also installs some packaged version
of tcl/tk into perl tree so to guarantee that the module works
for my $inc (@INC) {
my $tkkit = "$inc/auto/Tcl/tkkit.$Config::Config{so}";
if (-f $tkkit) {
$DL_PATH = $tkkit;
last;
}
}
> Any tips on how I can wire in the latest
> version of Tcl/Tk for Perl usage?
If it is on path - and you remove (or hide) tkkit.(dll/so) - then existing
tcl/tk should be use
RE: Check Tcl/Tk using Tcl.pm from Makefile.PL?
Hi Christofer, > I often have multiple Tcl/Tk installations on a system for testing purposes, > and quite a few times I have accidentally specified --tclsh for the wrong > Tcl/Tk installation to Tcl::pTk, rather than whichever one Tcl.pm is currently > using. > > I wonder if this could be prevented: when installing Tcl.pm dependents > (Tcl::pTk, Tcl::Tk, etc.), why not have them go through Tcl.pm to check for > Tcl/Tk versions and extensions, rather than relying on a possibly-incorrect > path to tclsh? I think your idea is reasonable, yes > Would it be okay for Tcl.pm dependents to `require Tcl` from > inside Makefile.PL (only when the --test-for-tk check is requested), or is it > considered universally "bad" for Makefile.PL files to try using dependencies > this way? Was there a reason this approach was not used in the first place? I think this was an overlook.
RE: Possible bug in Tcl.pm exposed by Tktable?
> On 4/7/2020 3:05 AM, Konovalov, Vadim wrote:
> > As a workaround, you can define
> this environment variable in Perl, then error goes away:
> >
> > vad@bonita:~$ perl
> -MTcl -we '$ENV{FOO}="x";my $i=new Tcl;$i->Eval("set env(FOO) bar");print
> qq/ok\n/'
> > ok
>
> I have not yet given this a try, but does this mean having to
> first set the exact environment variable Tcl sets, or is it
> that *any*
> environment variable needs to be set first from Perl?
Any environment variable needs to be set first from Perl - this will avoid
allocating its name in
>
> > Tcl uses "ckalloc"
> function to allocate strings for name of environment variable "FOO" (or a
> value?)
> > This 'ckalloc' is their helper function, which chains memory into
> link, so to free it after all.
> >
> > IMO If they just use "malloc" the problem
> will go away.
> > I haven't verified this assumption, but 85%-sure of it ??
>
> Because I compiled with -DPURIFY I've already verified this won't
> make a
> difference.
Are you stating that if I change in function "TclSetEnv" here ckalloc to malloc
and ckfree to free:
if (index == -1) {
#ifndef USE_PUTENV
/*
* We need to handle the case where the environment may be changed
* outside our control. ourEnvironSize is only valid if the current
* environment is the one we allocated. [Bug 979640]
*/
if ((env.ourEnviron != environ) || (length+2 > env.ourEnvironSize)) {
char **newEnviron = ckalloc((length + 5) * sizeof(char *));
memcpy(newEnviron, environ, length * sizeof(char *));
if ((env.ourEnvironSize != 0) && (env.ourEnviron != NULL)) {
ckfree(env.ourEnviron);
}
environ = env.ourEnviron = newEnviron;
env.ourEnvironSize = length + 5;
}
index = length;
environ[index + 1] = NULL;
#endif /* USE_PUTENV */
oldValue = NULL;
nameLength = strlen(name);
BTW what if you'll rebuild with USE_PUTENV?
>
> Without manually defining TCL_MEM_DEBUG, ckalloc() is Tcl_Alloc(),
> and Tcl_Alloc() uses TclpAlloc() directly.
> Defining PURIFY undefines
> USE_TCLALLOC, making TclpAlloc()
> use malloc() directly.
>
> This is evident in the valgrind stack trace I posted 2020-03-17.
That's cool
RE: Possible bug in Tcl.pm exposed by Tktable?
> https://rt.cpan.org/Ticket/Display.html?id=132278
> >
> > Can you open the ticket on Tcl.pm, given that we see that it is more
> > relevant here?
>
> I have moved the existing ticket to keep the reporter informed.
> I meant to adjust the title as well but couldn't do so once it moved.
Cool! Thank you!
>
> > I will work on the fix, when time permits
>
> Thanks. Indeed there should be no rush to fix this. It
> is a benign issue that might only pose a minor annoyance to users (e.g. "Your
> program has crashed, report it?" nags from OS); unsaved data does not appear
> to
> be in jeopardy because of it.
As a workaround, you can define this environment variable in Perl, then error
goes away:
vad@bonita:~$ perl -MTcl -we '$ENV{FOO}="x";my $i=new Tcl;$i->Eval("set
env(FOO) bar");print qq/ok\n/'
ok
OTOH error message differs a bit whether or not we 'unset' this environment
variable within tcl:
vad@bonita:~$ perl -MTcl -we 'my $i=new Tcl;$i->Eval("set env(FOO) bar;unset
env(FOO)");END{print qq/in END\n/}print qq/after all\n/'
after all
in END
double free or corruption (!prev)
Aborted (core dumped)
vad@bonita:~$ perl -MTcl -we 'my $i=new Tcl;$i->Eval("set env(FOO)
bar");END{print qq/in END\n/}print qq/after all\n/'
after all
in END
free(): invalid size
Aborted (core dumped)
When Perl uses $ENV{FOO} *after* tcl then there is error again:
vad@bonita:~$ perl -MTcl -we 'my $i=new Tcl;$i->Eval("set env(FOO)
bar");$ENV{FOO}="bar";print qq/ok\n/'
free(): invalid size
Aborted (core dumped)
vad@bonita:~$ perl -MTcl -we 'my $i=new Tcl;$i->Eval("set env(FOO) bar");print
qq/ok\n/'
ok
free(): invalid size
Aborted (core dumped)
vad@bonita:~$
vad@bonita:~$ perl -MTcl -we 'my $i=new Tcl;$i->Init;$i->Eval("set env(FOO)
bar");delete $ENV{FOO};print qq/deleted FOO\n/'
free(): invalid size
Aborted (core dumped)
vad@bonita:~$ perl -MTcl -we 'my $i=new Tcl;$i->Init;$i->Eval("set env(FOO)
bar;unset env(FOO)");END{print qq/in END\n/}print qq/after all\n/'
after all
in END
double free or corruption (!prev)
Aborted (core dumped)
vad@bonita:~$
Tcl uses "ckalloc" function to allocate strings for name of environment
variable "FOO" (or a value?)
This 'ckalloc' is their helper function, which chains memory into link, so to
free it after all.
IMO If they just use "malloc" the problem will go away.
I haven't verified this assumption, but 85%-sure of it
TODO list:
[x] find temporary workaround
[ ] see whether it is possible to redefine Tcl_PutEnv in Tcl.
[ ] profit
regards,
Vadim
RE: Possible bug in Tcl.pm exposed by Tktable?
> Thank you for investigating this in such great detail. > > > A Tcl::pTk user opened > a ticket observing this issue in the > test suite: > https://rt.cpan.org/Ticket/Display.html?id=132278 Can you open the ticket on Tcl.pm, given that we see that it is more relevant here? > > I had briefly looked online > for previous reports of similar issues > for Tcl and Perl, and there were plenty > of bug reports and improvements > submitted, often from 20+ years ago. I don't > think I came across > this exact issue. But in some cases this kind of issue was > deemed > expected behavior, so I wouldn't be surprised if raising this > specific > issue with either Perl or Tcl today that they still consider > it to be neither > new nor unexpected. For example, a program embedding > Tcl is supposed to do > things like use/redefine Tcl_PutEnv() > (see > https://www.tcl-lang.org/man/tcl8.6/TclLib/Environment.htm). I've browsed tcl source code and IMO I've found a bug here (which is not affecting logic and not causing coredumps, but makes some minor inefficiency) This isn't of any importancy though > But this would > appear to assume the program writer is/should be > in control of compiling and > packaging everything in their program. > It is not possible to do this when > intending for Tcl.pm reuse > existing Tcl or Perl installations, such as from > package managers. IMO linker will use your function, if you redefine it in your code and will pass it sooner to linker. So you can "neutralize" freeing environment variables in libtcl IOW Tcl.xs should redefine Tcl_PutEnv to "forward" this into perl's environment call - what is it? According to https://perldoc.perl.org/5.30.0/perlclib.html#_stdlib.h_-functions - this is my_setenv? > So maybe Tcl.pm will have to document this as a known issue. > > Or, is there a workaround possible in the meantime? I will work on the fix, when time permits
RE: Possible bug in Tcl.pm exposed by Tktable?
You're ingenious!
vad@bonita:~$ perl -MTcl -we 'my $i=new Tcl;$i->Init;$i->Eval("set env(FOO)
bar");'
free(): invalid size
Aborted (core dumped)
vad@bonita:~$
and even $i->Init not needed:
vad@bonita:~$ perl -MTcl -we 'Tcl::new->Eval("set env(FOO) bar");'
free(): invalid size
Aborted (core dumped)
Haven't looked deeper though, but the picture now is much more clear! Thanks!
-Original Message-
From: Christopher Chavez
Sent: Tuesday, March 17, 2020 6:08 AM
To: tcltk@perl.org
Subject: Re: Possible bug in Tcl.pm exposed by Tktable?
[EXTERNAL EMAIL]
On 3/16/2020 4:09 AM, Christopher Chavez wrote:
> To partially answer my own question:
> there are some compile-time techniques to try like -DPURIFY
> https://wiki.tcl-lang.org/page/How+to+debug+memory+faults+in+Tcl+and+e
> xtensions
After build from upstream sources (Tcl/Tk core-8-6-branch and TkTable 2.11 --
no Debian/Ubuntu Tcl/Tk packages) with -DPURIFY, the error is revealed to be a
double free. The addresses involved correspond to strings allocated for
environment variable(s) set by Tktable (tkTableInitScript.h).
A simpler program without Tk or Tktable reveals the same issue:
use Tcl;
my $i = new Tcl;
$i->Init;
$i->Eval('set env(FOO) bar');
Command line output:
free(): double free detected in tcache 2 Aborted (core dumped)
Valgrind output:
==13666== Invalid free() / delete / delete[] / realloc()
==13666==at 0x48369AB: free (vg_replace_malloc.c:530)
==13666==by 0x162304: perl_destruct (in /usr/bin/perl)
==13666==by 0x13C3DB: main (in /usr/bin/perl)
==13666== Address 0x5229a20 is 0 bytes inside a block of size 8 free'd
==13666==at 0x48369AB: free (vg_replace_malloc.c:530)
==13666==by 0x543EE86: TclpFree (tclAlloc.c:722)
==13666==by 0x5517935: TclFinalizeEnvironment (tclEnv.c:768)
==13666==by 0x5519268: Tcl_Finalize (tclEvent.c:1151)
==13666==by 0x485123D: XS_Tcl__Finalize (Tcl.xs:1449)
==13666==by 0x1F4360: Perl_pp_entersub (in /usr/bin/perl)
==13666==by 0x1EA685: Perl_runops_standard (in /usr/bin/perl)
==13666==by 0x15DF61: Perl_call_sv (in /usr/bin/perl)
==13666==by 0x160AC3: Perl_call_list (in /usr/bin/perl)
==13666==by 0x16235E: perl_destruct (in /usr/bin/perl)
==13666==by 0x13C3DB: main (in /usr/bin/perl)
==13666== Block was alloc'd at
==13666==at 0x4837D7B: realloc (vg_replace_malloc.c:826)
==13666==by 0x543EEAA: TclpRealloc (tclAlloc.c:747)
==13666==by 0x5456E8D: Tcl_Realloc (tclCkalloc.c:1147)
==13666==by 0x55172A9: TclSetEnv (tclEnv.c:317)
==13666==by 0x5517688: EnvTraceProc (tclEnv.c:636)
==13666==by 0x55A0B69: TclCallVarTraces (tclTrace.c:2678)
==13666==by 0x55A0860: TclObjCallVarTraces (tclTrace.c:2564)
==13666==by 0x55AAFDB: TclPtrSetVarIdx (tclVar.c:2001)
==13666==by 0x55AA957: Tcl_ObjSetVar2 (tclVar.c:1770)
==13666==by 0x55AA609: Tcl_SetObjCmd (tclVar.c:1529)
==13666==by 0x544A42A: Dispatch (tclBasic.c:4456)
==13666==by 0x544A4B0: TclNRRunCallbacks (tclBasic.c:4492)
==13666==by 0x5449D83: Tcl_EvalObjv (tclBasic.c:4215)
==13666==by 0x544C1AB: TclEvalEx (tclBasic.c:5361)
==13666==by 0x544B571: Tcl_EvalEx (tclBasic.c:5026)
==13666==by 0x48525A8: XS_Tcl_Eval (Tcl.xs:1097)
==13666==by 0x1F4360: Perl_pp_entersub (in /usr/bin/perl)
==13666==by 0x1EA685: Perl_runops_standard (in /usr/bin/perl)
==13666==by 0x166116: perl_run (in /usr/bin/perl)
==13666==by 0x13C401: main (in /usr/bin/perl)
==13666==
==13666== Invalid free() / delete / delete[] / realloc()
==13666==at 0x48369AB: free (vg_replace_malloc.c:530)
==13666==by 0x162322: perl_destruct (in /usr/bin/perl)
==13666==by 0x13C3DB: main (in /usr/bin/perl)
==13666== Address 0x5229810 is 0 bytes inside a block of size 376 free'd
==13666==at 0x48369AB: free (vg_replace_malloc.c:530)
==13666==by 0x543EE86: TclpFree (tclAlloc.c:722)
==13666==by 0x5517983: TclFinalizeEnvironment (tclEnv.c:776)
==13666==by 0x5519268: Tcl_Finalize (tclEvent.c:1151)
==13666==by 0x485123D: XS_Tcl__Finalize (Tcl.xs:1449)
==13666==by 0x1F4360: Perl_pp_entersub (in /usr/bin/perl)
==13666==by 0x1EA685: Perl_runops_standard (in /usr/bin/perl)
==13666==by 0x15DF61: Perl_call_sv (in /usr/bin/perl)
==13666==by 0x160AC3: Perl_call_list (in /usr/bin/perl)
==13666==by 0x16235E: perl_destruct (in /usr/bin/perl)
==13666==by 0x13C3DB: main (in /usr/bin/perl)
==13666== Block was alloc'd at
==13666==at 0x483577F: malloc (vg_replace_malloc.c:299)
==13666==by 0x543EE6C: TclpAlloc (tclAlloc.c:699)
==13666==by 0x5456D99: Tcl_Alloc (tclCkalloc.c:1059)
==13666==by 0x5517074: TclSetEnv (tclEnv.c:263)
==13666==by 0x5517688: EnvTraceProc (tclEnv.c:636)
==13666==by 0x55A0B69: TclCallVarTraces (tclTrace.c:2678)
==13666==by 0x55A0860: TclObjCallVarTraces (tclTrace.c:2564)
==13666==by 0x55AAFDB: TclPtrSetVarIdx (tclVar.c:2001)
==13666==by 0x55AA957: Tcl_ObjSetVar2 (tclVar.c:1770)
==13666==by
RE: trouble installing Tkx
> Christopher Chavez wrote: > > On 11/20/2019 11:25 AM, Dave Howorth wrote: > There's a bug #115662 for Tkx on rt.cpan.org that was opened three years > ago with no response. I appended my log to it yesterday, since I seem to > be encountering the same problem with newer software (I'm on openSUSE Leap > 15.0) > > > https://rt.cpan.org/Public/Bug/Display.html?id=115662 > > In the meantime I suggest using cpanm --force to install Tkx. This > > will ignore the single test failure that prevents installation. The > > failing test is merely for intentionally generating an error message, > > which still works but no longer produces the exact message that was > > hardcoded into the test long ago. > > > > Hope this helps Surely does IMO taking ownership on the module is the way to go, if Gisle Aas isn't arguing against this > > > Christopher A. Chavez > > Many thanks. I don't suppose there's a reason your pull > request hasn't been accepted yet. > > Cheers, Dave
RE: High DPI on Windows with Tk
Dell Customer Communication - Confidential
> > From: Christopher Chavez
> > To: tcltk
> > I wanted to
> share a way for using high-DPI appearance on Windows that I
> > found, in case
> anyone was interested. I have posted it to
> >
> https://www.perlmonks.org/?node_id=11101747
Thank you
Pretty nice
> > Before calling
> MainWindow->new in Tk, use Win32::API to invoke
> > SetProcessDPIAware():
> >
> > if ($^O eq 'MSWin32') {
> >use Win32::API;
Here should be 'require', not 'use'
> ># See
> > https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-setprocessdpiaware
> >my $SetProcessDPIAware = Win32::API::More->new('User32', 'BOOL
> > SetProcessDPIAware()');
> >$SetProcessDPIAware->Call() or warn 'Failed to set process DPI
> > awareness';
> > }
> >
> >
> > This isn't the approach Microsoft
> recommends (they suggest using an
> > application manifest instead), but this
> seems to be an easy enough approach
> > for standalone scripts.
> >
> >
> > Recent
> Tcl/Tk will enable high-DPI by default for scripts run using tclsh/wish,
> > but
> not the Tcl C API. I'm not sure this behavior should be the default in
> >
> Tcl::pTk, for compatibility (i.e. since Perl/Tk does not enable high-DPI) and
> >
> because certain elements like images will not be resized automatically.
> >
> >
> Maybe Tcl::Tk would be more in favor of having this behavior by default (for
> >
> consistency with Tcl/Tk), but it might require XS or dependency on another
> >
> module like Win32::API.
> >
> >
> > Christopher A. Chavez
RE: Likely Tcl.pm issue on PerlMonks
Thanks for pointing this out. Hi Jeff, What would be your best recommendation on the matter? IMO there are plenty of alternatives to ActiveTCL only because ActiveTCL (together with its teacup) became harder to use, therefore lot of binary builds have appeared: IronTCL, BAWT, etc. Should we recommend to BAWT to Tck::pTk users? -Original Message- From: Christopher Chavez Sent: Monday, May 13, 2019 2:23 AM To: tcltk@perl.org Subject: Likely Tcl.pm issue on PerlMonks [EXTERNAL EMAIL] Just want to share a recent question I found on PerlMonks, in case anyone else wants to take a look or can help: https://www.perlmonks.org/?node_id=1233609 The user was initially trying to get Tkx working with DWIM Perl + ActiveTcl but the error looks like it might be coming from Tcl.pm — “failed dlopen(…)”.
merge of Tcl::Tk and Tcl::pTk (RE: Drop support for Tcl/Tk 8.4?)
> They currently do support 8.4 and I am planning to continue support; > Even > 8.0 I supported > > Any signs that they don't? > > Not to my knowledge. > > One > reason I ask though is in consideration of the possibility of merging Tcl::pTk > and Tcl::Tk, which I have not made progress on. Even if I leave in > compatibility with 8.4, I might only be willing to "actively support" and test > on 8.5 or later. Good point However even if Tcl::Tk will drop 8.4, Tcl.pm still should support it; OTOH for now we should elaborate a plan of "merging" of Tcl::Tk and Tcl::pTk. In my opinion, nowadays the picture is this: - I see lots of "good" activity on github Tcl::pTk project; I pretty much like it - however IMO there is some, say, 5% of incompatibilities, which will never go away, So if you take random perl/Tk program - will it just run, after you'll replace "use Tk" with "use Tcl::pTk"? mostly - no (correct me if I am wrong) - but perlTk itself is "Tk-804.034" <-- it even mentions 8.4, which you intended to drop, so I see no very deep reason on having 100% compatibility. Syntax is good, but no more than that, 95 is enough (of course other people could have different opinion, I respect that other opinion) Yet, there is another point: Now Tcl::Tk is a single-file perl module, which fully allows perl-tk syntax; it is very tempting to have it single and thin and very lightweight. For me, perl/Tk syntax is preferable (together with pure-tcl) over some perl/Tk module that I could potentially use. To make both projects happy, I would think about following proposal: - I will move that single file of current Tcl::Tk Tcl/Tk.pm into Tcl.pm, renamed somehow. - ... which will be optionally called from Tcl, such as "use Tcl ':perltk'; - (while doing that I will remove lots of unneeded methods from there and will modernize it (no, this does not mean ''use warnings'' at all)) - then you could use Tcl::Tk namespace freely; merge and/or refer /or alias to each other; IDK whether this wins something, all these thoughts are fresh; So perl/Tk syntax will be (optionally) provided by "tcl.pm"; no care of perl/tk compat at all. This will mean Tcl::Tk in its current stage could leave and free space for better compatibility. PS. I must admit I haven't touched codebase of tcl.pm for several months already, but surely I am planning to return to this, soon :)
RE: Drop support for Tcl/Tk 8.4?
> > > > I am proposing to drop support for Tcl/Tk 8.4 from Tcl::pTk. > > Vadim, do > either of Tcl.pm and Tcl::Tk intend to continue supporting Tcl/Tk < 8.5 (if > they currently do)? They currently do support 8.4 and I am planning to continue support; Even 8.0 I supported Any signs that they don't?
merging Tcl::Tk and Tcl::pTk
Hi there, Al long as full compatibility between Tcl::pTk and perl/Tk haven't happened, I propose to spend some efforts on joining Tcl::Tk and Tck::pTk so to have some reasonable compatibility and single module so to not spread efforts among these? Regards, Vadim
RE: [macOS] Tcl::pTk Drag
Sorry for providing only “common sence” answer,
I do not have MacOS.
> Using Tcl::pTk I am trying to implement Drag on
> macOS without success. According to its documentation, Tcl::pTk should support
> it. This is what I am trying now (slightly adapted from my version for Windows
> and Perl/Tk):
> $MyWidget->DropSite(-dropcommand => [\_drop, $tap],
> -droptypes => (['Local', 'tkdnd']));
>
> sub accept_drop {
> my ($tab) = @_;
>
> my $filePath;
> eval {
> if ($^O eq 'MSWin32') {
> $filePath = $tab->SelectionGet(-selection => $selection,
> 'STRING');
> }
> else {
> $filePath =
> $tab->SelectionGet(-selection => $selection,
> 'FILE_NAME');
> }
> }
> #DO THINGS with $filePath
> }
>
> I have downloaded a binary of tkdnd (libtkdnd2.8.dylib). How do I
> let Tcl::pTk know of this library? Or there is any way to implement it without
> adding new libraries (I am using the Tcl shipped with macOS).
AFAIK Tcl::pTk is unaware whether or not you have ‘tkdnd’ or not in your tcl/tk
install, on top of which Tcl::pTk operates
First of all, you should make sure you can run demos from ‘tkdnd’.
You can ask about tkdnd installment on proper forums, so they will help you
with this.
Then, Tcl::pTk will be just fine.
Given that your Tcl::pTk program already runs ok, it should be the same on
macos.
Regards,
Vadim
RE: Escaping $tclsh in Makefile.PL
> From: Christopher Chavez > I haven't thought of an issue with using quotemeta > (presumably without double quotes) on UNIX though, since at least bash seems > fine with things being \-escaped. > > > Still, I'm somewhat uneasy about putting > this kind of logic, but it's probably better than leaving it how it currently > is, and there's little else to do with using core Perl. I don't think this makes the module more difficult to use Ideally, just "cpan" install command should work. If user wants customized build - then he already knows what she is doing. So we're talking about experienced users on windows, who wants to pass something weird to --tclsh= ? So if I have tclsh in whitespace-separated path, then double-quoting this command-line argument should suffice. Changing manually \ to / and placing into double-qoutes should work.
RE: Escaping $tclsh in Makefile.PL
I wonder if quotemeta enough?? -Original Message- From: Christopher Chavez [mailto:chrischa...@gmx.us] Sent: Wednesday, August 22, 2018 12:22 PM To: tcltk@perl.org Subject: Escaping $tclsh in Makefile.PL In the Makefile.PL's for Tcl.pm, Tcl::Tk, and Tcl::pTk, the path to tclsh should probably be escaped somehow. That way, any characters like spaces get passed properly to the shell. I don't know what the best portable way to do this would be, nor whether surrounding it with double quotes (i.e. `"$tclsh" ...`) is sufficient. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
RE: Error running Makefile.PL on Windows
It appears that on $^O MSWin32 both perl-5.8.4, 5.6.1 are good with our "Makefile.PL", Also "Cygwin" is good, and obviously "linux" + freebsd Perl-5.12 5.16 5.16 and 5.28 all fail with error starting tclsh: $?=-1; $!=Inappropriate I/O control operation error writing "stdout": broken pipe while executing "puts "tclsh=[info nameofexecutable]"" (file "tclcfg.tcl" line 1) IMO this is MSWin32 incompatibility WRT "$?" var. What we need to do is workaround which will ignore $? on win32. Report with perlbug to perl5-port...@perl.org? -Original Message- From: Konovalov, Vadim [mailto:vadim.konova...@dell.com] Sent: Monday, August 20, 2018 11:39 PM To: Christopher Chavez; tcltk@perl.org Subject: RE: Error running Makefile.PL on Windows OMG you're correct Will have a closer look tomorrow -Original Message- From: Christopher Chavez [mailto:chrischa...@gmx.us] Sent: Monday, August 20, 2018 11:01 PM To: tcltk@perl.org Subject: Re: Error running Makefile.PL on Windows On 8/20/2018 2:36 PM, Konovalov, Vadim wrote: >> I have a machine with Windows 10 64-bit 1803, ActivePerl* 5.24.3, and >> ActiveTcl 8.6.7. >> >> *(Uses dmake and doesn't have gnu make. I'm not constrained to >> ActivePerl; I just didn't know about Strawberry until recently.) > > If you think that "dmake" is source of trouble, then we can add > workaround in Makefile.PL to handle your case. > > You can add a code that checks these vars $? and $! differently > > fortunately, our Makefile.PL already has a stub to deal with dmake, so > you can benefit from it. > Fortunately I haven't encountered an issue with dmake specifically. I was checking to see if the past few commits of Tcl.pm would compile, and found the one from a few weeks ago when there were some suspicions over dmake causing compilation issues. The "dmake prohibited" message seemed to confuse ActivePerl for "modified" Strawberry Perl installation due to presence of dmake/lack of GNU make. But that message has since been reverted since the problem (if there is one) is believed to be elsewhere. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
RE: Error running Makefile.PL on Windows
OMG you're correct Will have a closer look tomorrow -Original Message- From: Christopher Chavez [mailto:chrischa...@gmx.us] Sent: Monday, August 20, 2018 11:01 PM To: tcltk@perl.org Subject: Re: Error running Makefile.PL on Windows On 8/20/2018 2:36 PM, Konovalov, Vadim wrote: >> I have a machine with Windows 10 64-bit 1803, ActivePerl* 5.24.3, and >> ActiveTcl 8.6.7. >> >> *(Uses dmake and doesn't have gnu make. I'm not constrained to >> ActivePerl; I just didn't know about Strawberry until recently.) > > If you think that "dmake" is source of trouble, then we can add > workaround in Makefile.PL to handle your case. > > You can add a code that checks these vars $? and $! differently > > fortunately, our Makefile.PL already has a stub to deal with dmake, so > you can benefit from it. > Fortunately I haven't encountered an issue with dmake specifically. I was checking to see if the past few commits of Tcl.pm would compile, and found the one from a few weeks ago when there were some suspicions over dmake causing compilation issues. The "dmake prohibited" message seemed to confuse ActivePerl for "modified" Strawberry Perl installation due to presence of dmake/lack of GNU make. But that message has since been reverted since the problem (if there is one) is believed to be elsewhere. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
RE: Error running Makefile.PL on Windows
> I have a machine with Windows 10 64-bit 1803, ActivePerl* 5.24.3, and > ActiveTcl 8.6.7. > > *(Uses dmake and doesn't have gnu make. I'm not constrained > to > ActivePerl; I just didn't know about Strawberry until recently.) If you think that "dmake" is source of trouble, then we can add workaround in Makefile.PL to handle your case. You can add a code that checks these vars $? and $! differently fortunately, our Makefile.PL already has a stub to deal with dmake, so you can benefit from it. Regards, Vadim
RE: partial photo/image tests without Img extension?
> I > notice that both Tcl::Tk and Tcl::pTk have some tests that currently require > the Img extension to handle image formats not included in Tcl/Tk. Would it be > desirable to still test the formats that are available (gif; png on Tk 8.6), > or > is the test more about exercising the capabilities in Img? Is it even possible > to plan a certain number of tests and then skip a subset of them? I didn't knew that png and gif are even good w/o Img extension Yes, your proposal is highly desireable :)
RE: Bypass test-for-tk.tcl?
Yes, you are welcome to introduce flag for Makefile.PL, you can use Tcl’s Makefile.PL as reference, or be on your own. But mostly Makefile.PL already have some code for appetizer. TIA, Vadim From: Christopher Chavez [mailto:chrischa...@gmx.us] Sent: Monday, July 30, 2018 3:14 PM To: tcltk@perl.org Subject: Bypass test-for-tk.tcl? For the MacPorts portfiles I made for both Tcl::Tk and Tcl::pTk, I currently use a patch to remove the `$tclsh test-for-tk.tcl` usage from Makefile.PL, since it doesn't work from MacPorts (either there is no X server available to the user that MacPorts runs as, or perl somehow isn’t getting any output from tclsh): cf. https://github.com/macports/macports-ports/pull/2036/files#diff-e284154b6d6ebcccb1e2d72b7d3d318f https://github.com/macports/macports-ports/pull/2231/files#diff-95d5f695478328ce2638066699edf49b https://trac.macports.org/ticket/56825 Would it be appropriate to add a flag for Makefile.PL to skip running test-for-tk, for uses such as MacPorts where (hopefully) any dependencies are already installed correctly. Then, all that’s needed by the portfiles are the flag, rather than a patch (which has to stay current with test-for-tk is being run). Or, some better alternative I haven’t thought of?
RE: status of fileevent support? (for use with Tcl::pTk)
> I use a variation on > https://www.nntp.perl.org/group/perl.tcltk/2011/03/msg524.html > with filrevents > in tkx to read from sockets. i use it to read from > http sourced ports as well > as stock sockets. Yes, that's pretty much reasonable :)
RE: status of fileevent support? (for use with Tcl::pTk)
> For the program I'm working on (cf. > https://github.com/hotwolf/HSW12/issues/16) the existing fileevent is for > reading a serial port. It already uses separate read and write filehandles; it > might be sufficient to use Tcl syntax to open a read handle for the device and > make a fileevent for it (from Tcl rather than Perl), while continuing to use a > Perl write filehandle in UI event callbacks. > For other uses, I'm not quite sure > what the best approach will be. It doesn't seem possible to use some modern > module like IO::Async in the same thread with e.g. Tcl::pTk due to separate > event loops. If combining the file handles is best, that seems like something > needing to be done from C/XS (not pure Perl or Tcl), which is what using > Tcl_CreateFileHandler would entail. My personal preference is to avoid perl threads - always, even with careful separation - GUI for one thread and all other for another. Perl threads are officially discouraged, so I don't. A point with different event loops for IO::Async and Tcl-based GUI-or-IO is a problem, indeed. A question - is it still a problem for perl/Tk? (actually I think so) Spinning 2 event loops is impossible, either by 2 threads or by one single thread with any tricks or whistles or prays. This means that a solution with tcl-only GUI and async-io is actually the preferred one. IOW you're correct with 'fileevent' question, :) In case you see that pure-tcl not possible and indeed you need to use API, including Tcl_CreateFileHandler, we could happily add that to XS.
RE: fatal error: tcl.h: No such file or directory
Ok I’ve made some another release 1.21,
but
https://www.cpantesters.org/cpan/report/d03c8124-8c09-11e8-8fb1-ef5133556b3f
--
PROGRAM OUTPUT
--
Output from '/mnt/nas/home/pi2/njh/perl5/perlbrew/perls/perl-5.12.5/bin/perl
Makefile.PL':
Can't open perl script "Makefile.PL": No such file or directory
How this could be??
From: Konovalov, Vadim [mailto:vadim.konova...@dell.com]
Sent: Friday, July 20, 2018 12:59 PM
To: S.J. Luo
Cc: tcltk@perl.org
Subject: RE: fatal error: tcl.h: No such file or directory
Very true. But why??
Thanks. ☺
From: S.J. Luo [mailto:sja...@gmail.com]
Sent: Friday, July 20, 2018 8:29 AM
To: Konovalov, Vadim
Subject: RE: fatal error: tcl.h: No such file or directory
Hi,
I have noticed some Linux and OpenBSD systems got failed in 1.20 while there
were no fail record on them since 1.15. Maybe we have to check both $? and
return value of open().
SJ
2018年7月20日 上午3:18，"Konovalov, Vadim"
mailto:vadim.konova...@dell.com>>寫道：
Bingo! That’s it. Thanks ☺
Fixed in 1.20; indeed the error is simple when looking back into it, moreover –
we already had similar lines in Makefile.PL
Meanwhile, I made a bit of “noisy” release, they will output some more
information from Tcl.xs during DLL load;
so these 1.19 and 1.20 should be rather development releases, but who cares.
Fortunately the last bug ever will be fixed in 1.21! ☺
From: S.J. Luo [mailto:sja...@gmail.com<mailto:sja...@gmail.com>]
Sent: Thursday, July 19, 2018 8:27 PM
To: tcltk@perl.org<mailto:tcltk@perl.org>
Subject: Re: fatal error: tcl.h: No such file or directory
> but we do have these lines I Makefile.PL now:
>
> ...
> $incpath = $tclcfg{TCL_INCLUDE_SPEC};
>
> # https://www.cpantesters.org/cpan/report/18397198-6bf4-1014-85e5-4e79f459b9c5
> # Tcl.xs:32:10: fatal error: tcl.h: No such file or directory
> if ($incpath) {
> my @tclh = grep {-f "$_/tcl.h"} $incpath=~/-I(\S+)/g;
> if ($#tclh==-1) {
> _die "incpath $incpath from your tclconfig $tclconfig does not provide tcl.h"
> }
> } else {_die "can not figure out incpath from your tclconfig $tclconfig"}
>
> How come this happen to avoid my otherwise perfect check??
Hi,
I got some try on Strawberry Perl. I got similar result without installing any
tcl binary distribution.
--
C:\strawberry\cpan\build\Tcl-1.16-0>perl Makefile.PL
'tclsh' is not recognized as an internal or external command,
operable program or batch file.
Use of uninitialized value $tclcfg{"tcl_library"} in pattern match (m//) at
Makefile.PL line 164.
Use of uninitialized value $tclver in substitution (s///) at Makefile.PL line
171.
Use of uninitialized value $tclver in concatenation (.) or string at
Makefile.PL line 182.
LIBS = -ltcl
Use of uninitialized value $incpath in concatenation (.) or string at
Makefile.PL line 190.
INC=
DEFINE =
tclConfig.sh =
Use of uninitialized value $incpath in string at Makefile.PL line 208.
Checking if your kit is complete...
Looks good
Warning (mostly harmless): No library found for -ltcl
Generating a dmake-style Makefile
Writing Makefile for Tcl
Writing MYMETA.yml and MYMETA.json
C:\strawberry\cpan\build\Tcl-1.16-0>dmake
cp Tcl.pm blib\lib\Tcl.pm
Running Mkbootstrap for Tcl ()
"C:\strawberry\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 644 "Tcl.bs"
"C:\strawberry\perl\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty --
Tcl.bs blib\arch\auto\Tcl\Tcl.bs 644
"C:\strawberry\perl\bin\perl.exe" "C:\strawberry\perl\lib\ExtUtils\xsubpp"
-typemap C:\strawberry\perl\lib\ExtUtils\typemap -typema
p C:\strawberry\cpan\build\Tcl-1.16-0\typemap Tcl.xs > Tcl.xsc
Please specify prototyping behavior for Tcl.xs (see perlxs manual)
"C:\strawberry\perl\bin\perl.exe" -MExtUtils::Command -e mv -- Tcl.xsc Tcl.c
gcc -c -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv -f
no-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"1.16\"
-DXS_VERSION=\"1.16\" "-IC:\strawberry\perl\lib\CORE" Tcl
.c
Tcl.xs:32:17: fatal error: tcl.h: No such file or directory
#include
^
compilation terminated.
dmake: Error code 129, while making 'Tcl.o'
--
The key is why it can pass the check Makefile.PL. In Strawberry Perl, the
following code got a weird result (Tcl.pm 1.16):
C:\strawberry\cpan\build\Tcl-1.16-0>perl -E "open(FH, 'foo |') or die; say 'I
am still alive';"
I am still alive
'foo' is not recognized as an internal or external command,
operable program or batch file.
It seems open() with pipe returns true even if there is no 'foo' program
existed. I my Cygwin environment, the same program gets following result
% perl -E "open(FH, 'foo |') or die; say 'I am still alive';"
Died at -e line 1.
The Strawberry Perl I use is 5.24.4 x86_64 version in Win7.
The result in Tcl.pm 1.18
http://matrix.cpantesters.org/?dist=Tcl%201.18;os=mswin32;perl=5.28.0;reports=1
seems to be caused from the same issue.
SJ
RE: fatal error: tcl.h: No such file or directory
Very true. But why??
Thanks. ☺
From: S.J. Luo [mailto:sja...@gmail.com]
Sent: Friday, July 20, 2018 8:29 AM
To: Konovalov, Vadim
Subject: RE: fatal error: tcl.h: No such file or directory
Hi,
I have noticed some Linux and OpenBSD systems got failed in 1.20 while there
were no fail record on them since 1.15. Maybe we have to check both $? and
return value of open().
SJ
2018年7月20日 上午3:18，"Konovalov, Vadim"
mailto:vadim.konova...@dell.com>>寫道：
Bingo! That’s it. Thanks ☺
Fixed in 1.20; indeed the error is simple when looking back into it, moreover –
we already had similar lines in Makefile.PL
Meanwhile, I made a bit of “noisy” release, they will output some more
information from Tcl.xs during DLL load;
so these 1.19 and 1.20 should be rather development releases, but who cares.
Fortunately the last bug ever will be fixed in 1.21! ☺
From: S.J. Luo [mailto:sja...@gmail.com<mailto:sja...@gmail.com>]
Sent: Thursday, July 19, 2018 8:27 PM
To: tcltk@perl.org<mailto:tcltk@perl.org>
Subject: Re: fatal error: tcl.h: No such file or directory
> but we do have these lines I Makefile.PL now:
>
> ...
> $incpath = $tclcfg{TCL_INCLUDE_SPEC};
>
> # https://www.cpantesters.org/cpan/report/18397198-6bf4-1014-85e5-4e79f459b9c5
> # Tcl.xs:32:10: fatal error: tcl.h: No such file or directory
> if ($incpath) {
> my @tclh = grep {-f "$_/tcl.h"} $incpath=~/-I(\S+)/g;
> if ($#tclh==-1) {
> _die "incpath $incpath from your tclconfig $tclconfig does not provide tcl.h"
> }
> } else {_die "can not figure out incpath from your tclconfig $tclconfig"}
>
> How come this happen to avoid my otherwise perfect check??
Hi,
I got some try on Strawberry Perl. I got similar result without installing any
tcl binary distribution.
--
C:\strawberry\cpan\build\Tcl-1.16-0>perl Makefile.PL
'tclsh' is not recognized as an internal or external command,
operable program or batch file.
Use of uninitialized value $tclcfg{"tcl_library"} in pattern match (m//) at
Makefile.PL line 164.
Use of uninitialized value $tclver in substitution (s///) at Makefile.PL line
171.
Use of uninitialized value $tclver in concatenation (.) or string at
Makefile.PL line 182.
LIBS = -ltcl
Use of uninitialized value $incpath in concatenation (.) or string at
Makefile.PL line 190.
INC=
DEFINE =
tclConfig.sh =
Use of uninitialized value $incpath in string at Makefile.PL line 208.
Checking if your kit is complete...
Looks good
Warning (mostly harmless): No library found for -ltcl
Generating a dmake-style Makefile
Writing Makefile for Tcl
Writing MYMETA.yml and MYMETA.json
C:\strawberry\cpan\build\Tcl-1.16-0>dmake
cp Tcl.pm blib\lib\Tcl.pm
Running Mkbootstrap for Tcl ()
"C:\strawberry\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 644 "Tcl.bs"
"C:\strawberry\perl\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty --
Tcl.bs blib\arch\auto\Tcl\Tcl.bs 644
"C:\strawberry\perl\bin\perl.exe" "C:\strawberry\perl\lib\ExtUtils\xsubpp"
-typemap C:\strawberry\perl\lib\ExtUtils\typemap -typema
p C:\strawberry\cpan\build\Tcl-1.16-0\typemap Tcl.xs > Tcl.xsc
Please specify prototyping behavior for Tcl.xs (see perlxs manual)
"C:\strawberry\perl\bin\perl.exe" -MExtUtils::Command -e mv -- Tcl.xsc Tcl.c
gcc -c -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv -f
no-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"1.16\"
-DXS_VERSION=\"1.16\" "-IC:\strawberry\perl\lib\CORE" Tcl
.c
Tcl.xs:32:17: fatal error: tcl.h: No such file or directory
#include
^
compilation terminated.
dmake: Error code 129, while making 'Tcl.o'
--
The key is why it can pass the check Makefile.PL. In Strawberry Perl, the
following code got a weird result (Tcl.pm 1.16):
C:\strawberry\cpan\build\Tcl-1.16-0>perl -E "open(FH, 'foo |') or die; say 'I
am still alive';"
I am still alive
'foo' is not recognized as an internal or external command,
operable program or batch file.
It seems open() with pipe returns true even if there is no 'foo' program
existed. I my Cygwin environment, the same program gets following result
% perl -E "open(FH, 'foo |') or die; say 'I am still alive';"
Died at -e line 1.
The Strawberry Perl I use is 5.24.4 x86_64 version in Win7.
The result in Tcl.pm 1.18
http://matrix.cpantesters.org/?dist=Tcl%201.18;os=mswin32;perl=5.28.0;reports=1
seems to be caused from the same issue.
SJ
RE: Separate lists for user and dev discussion; centralized forum; watching for questions?
All users welcome here, separate list is not possible under perl.org address, but the current one is good enough for both developers and user. You can forward perlmonks or stackoverflow users here, also 'perldoc Tcl' mentions this ML Regards, Vadim -Original Message- From: Christopher Chavez [mailto:chrischa...@gmx.us] Sent: Friday, July 20, 2018 8:43 AM To: tcltk@perl.org Subject: Separate lists for user and dev discussion; centralized forum; watching for questions? (See discussion on RT #125878: https://rt.cpan.org/Ticket/Display.html?id=125878 ) There’s been quite a bit of dev-related traffic on this list recently, although the total volume is still low (only a dozen or so threads from past couple years). Would it be possible/ideal to separate user- and dev-related (and possibly bug-) discussions into another list? Also, a user proposes a forum or other centralized way of discussing Perl/Tk alternatives, particularly Tcl::pTk on macOS aqua, since that seems to be what I and many of the other users of that module I’ve encountered are using it for. Any thoughts, or possible existing places to try? Some users have posted questions on Perlmonks and StackOverflow over the past couple months, and just today did it occur to me to go look for them. Is there a better way besides reminding myself to check those on occasion?
RE: fatal error: tcl.h: No such file or directory
Bingo! That’s it. Thanks ☺
Fixed in 1.20; indeed the error is simple when looking back into it, moreover –
we already had similar lines in Makefile.PL
Meanwhile, I made a bit of “noisy” release, they will output some more
information from Tcl.xs during DLL load;
so these 1.19 and 1.20 should be rather development releases, but who cares.
Fortunately the last bug ever will be fixed in 1.21! ☺
From: S.J. Luo [mailto:sja...@gmail.com]
Sent: Thursday, July 19, 2018 8:27 PM
To: tcltk@perl.org
Subject: Re: fatal error: tcl.h: No such file or directory
> but we do have these lines I Makefile.PL now:
>
> ...
> $incpath = $tclcfg{TCL_INCLUDE_SPEC};
>
> # https://www.cpantesters.org/cpan/report/18397198-6bf4-1014-85e5-4e79f459b9c5
> # Tcl.xs:32:10: fatal error: tcl.h: No such file or directory
> if ($incpath) {
> my @tclh = grep {-f "$_/tcl.h"} $incpath=~/-I(\S+)/g;
> if ($#tclh==-1) {
> _die "incpath $incpath from your tclconfig $tclconfig does not provide tcl.h"
> }
> } else {_die "can not figure out incpath from your tclconfig $tclconfig"}
>
> How come this happen to avoid my otherwise perfect check??
Hi,
I got some try on Strawberry Perl. I got similar result without installing any
tcl binary distribution.
--
C:\strawberry\cpan\build\Tcl-1.16-0>perl Makefile.PL
'tclsh' is not recognized as an internal or external command,
operable program or batch file.
Use of uninitialized value $tclcfg{"tcl_library"} in pattern match (m//) at
Makefile.PL line 164.
Use of uninitialized value $tclver in substitution (s///) at Makefile.PL line
171.
Use of uninitialized value $tclver in concatenation (.) or string at
Makefile.PL line 182.
LIBS = -ltcl
Use of uninitialized value $incpath in concatenation (.) or string at
Makefile.PL line 190.
INC=
DEFINE =
tclConfig.sh =
Use of uninitialized value $incpath in string at Makefile.PL line 208.
Checking if your kit is complete...
Looks good
Warning (mostly harmless): No library found for -ltcl
Generating a dmake-style Makefile
Writing Makefile for Tcl
Writing MYMETA.yml and MYMETA.json
C:\strawberry\cpan\build\Tcl-1.16-0>dmake
cp Tcl.pm blib\lib\Tcl.pm
Running Mkbootstrap for Tcl ()
"C:\strawberry\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 644 "Tcl.bs"
"C:\strawberry\perl\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty --
Tcl.bs blib\arch\auto\Tcl\Tcl.bs 644
"C:\strawberry\perl\bin\perl.exe" "C:\strawberry\perl\lib\ExtUtils\xsubpp"
-typemap C:\strawberry\perl\lib\ExtUtils\typemap -typema
p C:\strawberry\cpan\build\Tcl-1.16-0\typemap Tcl.xs > Tcl.xsc
Please specify prototyping behavior for Tcl.xs (see perlxs manual)
"C:\strawberry\perl\bin\perl.exe" -MExtUtils::Command -e mv -- Tcl.xsc Tcl.c
gcc -c -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv -f
no-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"1.16\"
-DXS_VERSION=\"1.16\" "-IC:\strawberry\perl\lib\CORE" Tcl
.c
Tcl.xs:32:17: fatal error: tcl.h: No such file or directory
#include
^
compilation terminated.
dmake: Error code 129, while making 'Tcl.o'
--
The key is why it can pass the check Makefile.PL. In Strawberry Perl, the
following code got a weird result (Tcl.pm 1.16):
C:\strawberry\cpan\build\Tcl-1.16-0>perl -E "open(FH, 'foo |') or die; say 'I
am still alive';"
I am still alive
'foo' is not recognized as an internal or external command,
operable program or batch file.
It seems open() with pipe returns true even if there is no 'foo' program
existed. I my Cygwin environment, the same program gets following result
% perl -E "open(FH, 'foo |') or die; say 'I am still alive';"
Died at -e line 1.
The Strawberry Perl I use is 5.24.4 x86_64 version in Win7.
The result in Tcl.pm 1.18
http://matrix.cpantesters.org/?dist=Tcl%201.18;os=mswin32;perl=5.28.0;reports=1
seems to be caused from the same issue.
SJ
RE: Tcl::Tk for MacPorts
> From: Christopher Chavez > Alongside > existing ports in MacPorts for Tcl.pm, Tkx, and Tcl::pTk, I have added the a > port for Tcl::Tk, p5-tcl-tk. Bravo! I think we could place such a brief notice into README of tcl.pm (or maybe create INSTALL file explaining how to install on various OS?) Hasta la vista,☺ Vadim
RE: fatal error: tcl.h: No such file or directory
> From: Konovalov, Vadim > > Hi, > > Such an error I can not reproduce: > https://www.cpantesters.org/cpan/report/6abf7f68-6d61-1014-8cbe-f6af8038f308 > > Tcl.xs:32:10: fatal error: tcl.h: No such file or directory C:\vad\perl-dev\tcl.pm>gmake INC= cp Tcl.pm blib\lib\Tcl.pm Running Mkbootstrap for Tcl () "C:\apps\perl-5.26.0-32\perl\bin\perl.EXE" -MExtUtils::Command -e chmod -- 644 "Tcl.bs" "C:\apps\perl-5.26.0-32\perl\bin\perl.EXE" -MExtUtils::Command::MM -e cp_nonempty -- Tcl.bs blib\arch\auto\Tcl\Tcl.bs 64 4 "C:\apps\perl-5.26.0-32\perl\bin\perl.EXE" "C:\apps\perl-5.26.0-32\perl\lib\ExtUtils/xsubpp" -typemap C:\apps\perl-5.26 .0-32\perl\lib\ExtUtils\typemap -typemap C:\vad\perl-dev\tcl.pm\typemap Tcl.xs > Tcl.xsc Please specify prototyping behavior for Tcl.xs (see perlxs manual) "C:\apps\perl-5.26.0-32\perl\bin\perl.EXE" -MExtUtils::Command -e mv -- Tcl.xsc Tcl.c gcc -c -s -O2 -DWIN32 -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DU SE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"1.16\" -DXS_VERSION=\"1.16\" "-IC:\apps\perl -5.26.0-32\perl\lib\CORE" Tcl.c Tcl.xs:32:10: fatal error: tcl.h: No such file or directory #include ^~~ compilation terminated. gmake.EXE: *** [Makefile:338: Tcl.o] Error 1 I wonder if dmake have such a behaviour that it undefines INC? Or what? How to avoid? > > I see in log: > Please specify prototyping behavior for Tcl.xs (see perlxs manual) > "C:\Strawberry\perl\bin\perl.exe" -MExtUtils::Command -e mv -- Tcl.xsc Tcl.c > gcc -c -s -O2 -DWIN32 -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS > -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv > -fno-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"1.16\" > -DXS_VERSION=\"1.16\" "-IC:\STRAWB~1\perl\lib\CORE" Tcl.c >
RE: Tcl.pm tests in repo but omitted from releases
> From: Christopher Chavez > There's > a few tests in the git repository for Tcl.pm which aren't in the releases (not > in MANIFEST?): > dispsosal-subs-[abcdef].t, memleak-a.t, and set-callback.t. Nice catch. Thank you, now fixed, :) > Are > these being excluded on purpose (i.e. they are developer-only rather than > installation tests), or should they be included in releases? > > Also, some of > them (disposal-subs-a.t and memleak-a.t) use Devel::Refcount, which isn't > declared as a test dependency in Makefile.PL. Right now I prefer to have fewer dependencies; however I will install Devel::Refcount on my PCs :)
RE: Tcl procedure 'winfo' not found at ...
> I have noticed the returned value '3 (wstat 768, 0x300)' from you differs > from that of '2 (wstat 512, 0x200)' reported from CPAN tester. > In my Cygwin > environment, I also got a result 'Dubious, test returned 3 (wstat 768, 0x300)' > if I run 'make test' without DISPLAY; while I got 'Dubious, test returned 111 > (wstat 28416, 0x6f00)' if I set a wrong DISPLAY. > >It is possible that fail > not due to DISPLAY setting. FYI. Correct I am keeping an eye on the problem, Meanwhile, making another release today:) > SJ >
Tcl::Tk now comes with tcl snit
Hi Unfortunately sometimes 'snit' and 'tklib' are not available (e.g. on current Cygwin) So I've made to bring some backup copy together with Tcl::Tk; https://github.com/vadrer/perl-tcl-tk/commit/2c0ab2e6380c1d6fecb04381e20e2bef5df146a8 Regards, Vadim
Tcl procedure 'winfo' not found at ...
Have anyone reproduce of this, or explanation on what could cause this? http://www.cpantesters.org/cpan/report/29e842b4-8019-11e8-9bb2-e7af5549a355 ... Output from '/usr/bin/make test': PERL_DL_NONLAZY=1 "/opt/perl-5.28.0t/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t Tcl procedure 'winfo' not found at /home/cpansand/.cpan/build/2018070505/Tcl-Tk-1.10-11/blib/lib/Tcl/Tk.pm line 575. t/after.t ... Dubious, test returned 2 (wstat 512, 0x200) Failed 6/6 subtests ... etc It looks like failure to load Tk package (wrong DISPLAY var?) - but then - how this passed Makefile.PL check? TIA, Vadim
--buildspec will go away (RE: what is sub-makefile and when it is used?)
Tldr: subj
Longer explanation is this.
m-kay,
Makefile.PL is now greatly improved and a bit reworked,
Also "perl Makefile.PL --help" is introduced and adviced in README
--buildspec seems to me too much internal-specific;
Actually, looking into tclConfig.sh and then choosing for linker among these 4
variables:
TCL_LIB_SPEC
TCL_BUILD_LIB_SPEC
TCL_STUB_LIB_SPEC
TCL_BUILD_STUB_LIB_SPEC
# String to pass to linker to pick up the Tcl library from its build directory.
TCL_BUILD_LIB_SPEC=''
# String to pass to linker to pick up the Tcl library from its installed
directory.
TCL_LIB_SPEC='C:\apps\tcl-866-as86\lib\tcl86t.lib'
# String to pass to linker to pick up the Tcl stub library from its build
directory.
TCL_BUILD_STUB_LIB_SPEC='-L.\Release_VC13 tclstub86.lib'
# String to pass to linker to pick up the Tcl stub library from its installed
directory.
TCL_STUB_LIB_SPEC='-LC:\apps\tcl-866-as86\lib tclstub86.lib'
Is it helpful inside Makefile.PL without digging into tclConfig.sh
NO
Will go away?
YES
If anyone wants using it - no-one stops him from using "expert option"
--library=... --innclude=... which is here to serve all the needs
Ok, next move - move README to README.md
Thanks for listening :)
-Original Message-----
From: Konovalov, Vadim [mailto:vadim.konova...@dell.com]
Sent: Sunday, June 24, 2018 11:05 PM
To: tcltk@perl.org
Subject: what is sub-makefile and when it is used?
Hi,
In Tcl, Makefile.PL reads:
# This is to allow propagation of this value to sub-Makefile.PLs
$ENV{'TCLSH_PROG'} = $tclsh;
Going to get rid of this;
Does Tkx somehow depend on this?
Same thing for these lines in Tcl::Tk's Makefile.PL :
# Allow the tclsh prog to be provided by env var or arg if ($tclshArg) {
$tclsh = $tclshArg;
} elsif (defined($ENV{'TCLSH_PROG'})) {
$tclsh = $ENV{'TCLSH_PROG'};
}
Going to get rid of this as well; who use this?
TIA,
Vadim
what is sub-makefile and when it is used?
Hi,
In Tcl, Makefile.PL reads:
# This is to allow propagation of this value to sub-Makefile.PLs
$ENV{'TCLSH_PROG'} = $tclsh;
Going to get rid of this;
Does Tkx somehow depend on this?
Same thing for these lines in Tcl::Tk's Makefile.PL :
# Allow the tclsh prog to be provided by env var or arg
if ($tclshArg) {
$tclsh = $tclshArg;
} elsif (defined($ENV{'TCLSH_PROG'})) {
$tclsh = $ENV{'TCLSH_PROG'};
}
Going to get rid of this as well; who use this?
TIA,
Vadim
RE: facing trouble installing Tkx
> From: Syed Adnan Haider | Scientific Officer > > Hope you are doing good. While trying to install Tkx on my > UBUNTU 14.04, I am facing following bugs, which are not > letting me install it. > > Here is the error produced while installing, Kindly have a > look and sugges me some possible workaround or patch in > order to fix this. Thanks As I see it - all these errors could be ignored, you can ignore these errors with "force" flag like this: cpan -f -i Tkx however you've discovered some bug (which will not affect anything crucial, as I hope:) therefore I've made another CPAN release, please try the newer version 1.05, which also includes recent additions from some users. regards, Vadim.
[dev] searching for tkkit.dll
Hi,
Please notice recent addition to githib.com/gisle/tcl.pm bebe163
https://github.com/gisle/tcl.pm/commit/bebe163d3773784062b63323d96a923eee272ba5
Tcl.pm is not going to seek for tkkit.dll in $path anymore, mostly because it
appears to 1) always re-quire Config, which I was very much eager to avoid in
general case and only use if nothing more left to do.
Config.pm is the waste of CPU ticks.
But most important is 2) that it could happen to be faced sooner than correct
DLL, which also required to be non-movable and impossible to PAR and - what
most important - 0+) - is of about more restrictive License.
This module which wants to make tkkit.dll usable from Tcl must include these
lines before of "use Tcl;" line
sub Tcl::seek_tkkit {
unless ($DL_PATH) {
require Config;
for my $inc (@INC) {
my $tkkit = "$inc/auto/Tcl/tkkit.$Config::Config{so}";
if (-f $tkkit) {
$DL_PATH = $tkkit;
last;
}
}
}
}
I left a hook in Tcl.pm for this:
seek_tkkit() if defined _tkkit;
Regards,
Vadim.
RE: Tcl/Tk in par exe
> From: Kevin Walzer [mailto:k...@codebykevin.com]
> On 9/22/15 10:24 AM, Konovalov, Vadim wrote:
> > Should work, if you place all tcl/tk files as subdir and
> then PAR-pack
> > it into .par archive and "point" tcl_library there
> Well, this suggestion didn't quite work as presented, but
> it pointed me in the right direction--thanks.
It could be that you should also call $int->Init at the right time.
This is a function that I happen to insert into the Tcl.pm file, could help to
understand an idea on what I meant:
sub new {
my $int = _new(@_);
if ($ENV{PAR_PROGNAME}) {
#$int->SetVar('tcl_library',"$ENV{PAR_TEMP}\\inc\\tcl-togo/lib/tcl8.5");
Tcl::SetPreInitScript("set tcl_library
{$ENV{PAR_TEMP}/inc/tcl-togo/lib/tcl8.5}; source \"\$::tcl_library/init.tcl\"");
$int->Eval(
'package ifneeded Tk 8.5.13 [list load {' . "$ENV{PAR_TEMP}\\".
'tk85.dll} Tk]'
);
$int->Init;
}
return $int;
}
In my setup this works, although I expected to spend less time to make it to
work.
> I just did a brute force copy of the Tcl installation to
> one of the temp directories that the bundled Tcl.dll was
> looking for init.tcl. Crude, but it works. Now, on to
> fixing the auto_path to load additional packages...
Maybe this is the right way to go.
Regards,
Vadim.
RE: Tcl/Tk in par exe
You need to "play" with $tcl_library tcl variable,
$::tcl_library = 'some dir';
if (exists $ENV{PAR_TEMP}) {
$::tcl_library = "$ENV{PAR_TEMP}\\inc";
}
$int->SetVar('tcl_library',"$::tcl_library1/lib/tcl8.5");
$int->Eval($Tcl::init_scripts{'tcl8.5/init.tcl'}); # or you can feed the
file with "source" tcl command
(I've "slurped" some tcl init scripts into perl hash and eval it from there,
you can just place these where PAR unpacks and "point" it to the tcl/tk)
Should work, if you place all tcl/tk files as subdir and then PAR-pack it into
.par archive and "point" tcl_library there
-Original Message-
From: Kevin Walzer [mailto:k...@codebykevin.com]
Sent: Tuesday, September 22, 2015 2:00 PM
To: tcltk@perl.org
Subject: Re: Tcl/Tk in par exe
Following up on this:
I've been able to pack the Tcl and Tk dll's using the "-l" flag with calling
pp/par. However, it does not know where to unpack the rest of the Tcl
installation in such a way that the app can find them.
Can't find a usable init.tcl in the following directories:
C:/Users/kevin/AppData/Local/Temp/par-kevin/lib/tcl8.5 C:/Users/kevin/
AppData/Local/Temp/par-kevin/lib/tcl8.5 C:/Users/kevin/AppData/Local/Temp/li
b/tcl8.5 C:/Users/kevin/AppData/Local/Temp/par-kevin/library
C:/Users/kevin/AppData/Local/Temp/library
C:/Users/kevin/AppData/Local/Temp/tcl8.6.4/library
C:/Users/kevin/AppData/Local/tcl8.6.4/library
I've seen others on this list report that they use a Tcl/Tk installation rather
than ActiveState's tkkit bits to run Tkx. They've also said they can deploy
standalone apps with par. Therefore, there should be a way to get the Tcl
scripts installed correctly. Can anyone give me some insight on how to do
this--where to set up the par installation, how to initialize it in code? Vadim?
--Kevin
--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
RE: Exposing Tcl commands via Perl Tkx for Apple Event IPC
From: Kevin Walzer [mailto:k...@codebykevin.com]
The solution was so simple and elegant it astounded me:
Tkx::tclAE__installEventHandler (Perl, hihi, \hello);
In other words, pass the reference to the subroutine, just like a command
callback, and the Tkx bridge takes care of mapping it internally to a Tcl
command and then returning the correct output first to the app, then to the
calling AppleScript.
Amazing. I've been beating my head against a wall for a week trying to get
this to work at the C level, without results. This opens up all kinds of
things
for my projects--thank you so much for the terrific work!
Hi Kevin,
Sorry for not replying earlier, when you haven't figured out the solution yet.
I want to add, that - while you've found correct solution, there is some more
TIMTOWTDI that I regularly use.
For a long time already I more heavily use just Tcl module, with only minimal
addition of higher-level modules (like Tkx or Tcl::Tk in my case)
You can just do
$int-Eval('.'); # include any multiline code here to create widgets or
whatever
And then
$int-call('cmd', 'arg1', 'etc'); # for tcl/tk commands
$int-icall('.widget.some.thing', 'widgetmeth', 'etc'); # for tcl/tk commands
that do not involve perl references
$int-icall('.widget.some.thing', '-command', 'puts hello'}); # ... do not
involve perl references
$int-call('.widget.some.thing', '-command', sub{print 'hello'}); # here sub {}
- binded to tcl/tk counterpart
'icall' faster than 'call' and it does not do any perl reference to tcl binding.
While I am using Tcl::Tk instead of Tkx - both are on top of same Tcl module,
just different syntax - the same apply.
Regards,
Vadim.
RE: Tkx socket server can't read input
sub handle_connection {
my ($client) = shift;
my $message;
$message = Tkx::gets($client);
if ( defined $message and $message !~ /^quit/ ) {
$message =~ s/[\r\n]+$//;
$log-insert( 'end', $message\n );
$log-see('end');
}
else {
print connection closed\n;
$log-insert( 'end', connection closed\n );
$log-see('end');
$client-close();
}
}
this works bettr:
sub handle_connection {
my ($client) = shift;
my $message = Tkx::gets($client);
if ( !Tkx::eof($client) ) {
$message =~ s/[\r\n]+$//;
$log-insert( 'end', $message\n );
}
else {
print connection closed\n;
$log-insert( 'end', connection closed\n );
eval {Tkx::close($client);}; ## this was incorrect - $client-close();
}
$log-see('end');
}
RE: Tkx socket server can't read input
Here is the client script:
#!/usr/bin/perl
use IO::Socket;
my $machine_addr = 'localhost';
$sock = new IO::Socket::INET(PeerAddr=$machine_addr,
PeerPort=,
Proto='tcp',
);
die Could not connect: $! unless $sock;
foreach my $count(1..5){
print $sock $count\n;
print $count\n;
}
I've added here:
print $sock quit\n;
but the script could be fixed to run even without this.
close ($sock);
And the server script:
use strict;
use warnings;
use Tkx;
Tkx::package_require('tile');
my $mw = Tkx::widget-new(.);
my $server = Tkx::socket(-server = [\new_connection], );
my $log = $mw-new_tk__text(
-height = 10,
-width = 60,
-wrap = 'none'
);
$log-g_grid( -column = 0, -row = 0 );
Tkx::fconfigure($server, -blocking = 0);
#Tkx::fileevent( $server, readable = [\new_connection, \$server] );
Tkx::MainLoop();
sub new_connection {
my $client = shift;
Tkx::fconfigure($client, -blocking = 0);
Tkx::fileevent( $client, readable =[\handle_connection, \$client]);
notice that you pass REFERENCE to scalar, hence - in the handler
that variable should be de-referenced.
Alternately, pass not the reference, but $client variable itself.
No need to have reference here.
$log-insert( 'end', connected\n );
$log-see('end');
Tkx::update();
}
sub handle_connection {
my ($client) = shift;
my $message;
my $n;
# eval { $message = Tkx::gets($client, $n); };
$message = Tkx::gets($client, $n);
this must be done this way:
$message = Tkx::gets($client);
According to TCL documentation:
gets channelId ?varName?
DESCRIPTION
.
If varName is omitted the line is returned as the result of the command. If
varName is specified then the line is placed in the variable by that name and
the return value is a count of the number of characters returned.
you should either omit that $n or pass a reference to it but in this case you
get returned length, not the content, hence this is not what you want
if ( defined $message and $message !~ /^quit/ ) {
$message =~ s/[\r\n]+$//;
$log-insert( 'end', $message\n );
$log-see('end');
Tkx::update();
}
else {
print connection closed\n;
$log-insert( 'end', connection closed\n );
$log-see('end');
Tkx::update();
$client-close();
}
}
After these small fixes I see the communication just fine.
I understand that on the server side, using normal Perl sockets won't
work because they don't integrate with Tk's event loop, hence
using Tcl
sockets (exposed via Tkx) is necessary;
I am not socket expert, but looks like your approach with fileevent from Tcl
side
is the good one...
Regards,
Vadim.
RE: ptkdb vs tkdb
Hi Matthew, the most recent version of tkdb is on CPAN, which is Devel-tkdb. Look at Changes file on what changes were done to the ptkdb debugger, http://cpansearch.perl.org/src/VKON/Devel-tkdb-2.2/Changes e.g. the lines event loop (main_loop) is much better: it does not cycle eating CPU, instead waits (most important change IMO, is it will not eat the battery of your notebook while you're debugging :) ) Actually I can say that - during development - I ran the tkdb debugger in a specially constructed huge program of 150k lines (!) and it was really fast and responsive! perl -we print qq/\$a++;\nprint \$a;\n/ x 75000 | perl -d:tkdb is quite fast. tkdb actually lacks about 2-3 days of development time to have it feature-finished and really cool :) Maybe eventually I finish it. Surely I'll restart tkdb after all other important things are finished :) PS. Je ne connais pas votre ami, this is not surprising, because I am living near the edge of the World, while your collage friend presumably is closer to the centre :) Regards, Vadim. From: Matthew Persico [mailto:matthew.pers...@gmail.com] Sent: Friday, March 15, 2013 3:23 PM To: Konovalov, Vadim (Vadim)** CTR ** Subject: Fwd: ptkdb vs tkdb Vadim, Where can I get the latest version of tkdb? I am in the process of making some changes to ptkdb and I'd like to see if any of your upgraded functionality can be used in ptkdb. I have already made some changes to ptkdb that I can share with you if you like. Thanks PS - I see you work at alcatel-lucent. Do you know a Joseph Knobloch? I believe he works there. We went to college together. From: Konovalov, Vadim (Vadim)** CTR ** [mailto:vadim.konova...@alcatel-lucent.commailto:vadim.konova...@alcatel-lucent.com] Sent: Thursday, January 17, 2013 6:34 AM To: Persico, Matthew; 'aep...@users.sourceforge.netmailto:aep...@users.sourceforge.net'; 'nob...@home.netmailto:nob...@home.net'; 'v...@cpan.orgmailto:v...@cpan.org' Cc: tcltk@perl.orgmailto:tcltk@perl.org Subject: RE: ptkdb vs tkdb Hi, As you may know, ptkdb uses perl/Tk. I - personally - moved to perl+Tcl/tk out from perl/Tk (many years ago) and never return back. For usage of debugger - I adopted ptkdb for perl+Tcl/Tk Now - if you're using perl/Tk - then do use ptkdb, if you're using perl+Tcl/Tk - then do use tkdb. During adoption, I greatly reduced the size of debugger, greatly improved (now it can debug autogenerated script of size 150k lines, for example)) Also I throwed away obsoleted technologies in ptkdb, but then I left it unfinished, in the middle. Maybe someday the work will be finished. maybe not. Please let us know if you have actual interest in it. Regards, Vadim. From: Persico, Matthew [mailto:mpers...@knight.commailto:mpers...@knight.com] Sent: Wednesday, January 16, 2013 7:06 PM To: 'aep...@users.sourceforge.netmailto:aep...@users.sourceforge.net'; 'nob...@home.netmailto:nob...@home.net'; 'v...@cpan.orgmailto:v...@cpan.org' Subject: ptkdb vs tkdb Gentlemen, After a few years of being off in the wilderness of other languages I am returning to Perl. When searching for a piece of information about ptkdb, I encountered tkdb, some of whose documentation appears to be lifted right out of the ptkdb page. I also see that the tkdb page and AEP listed as an author. So, what’s the deal? Is tkdb the anointed successor to ptkdb? Or a sibling? Thanks, Matthew Persico, Vice President T 201 963 2525tel:201%20963%202525 mpers...@knight.commailto:mpers...@knight.com | www.knight.comhttp://www.knight.com [cid:828494711@18032013-1D4A] Knight Capital Americas LLC 545 Washington Blvd. | Jersey City, NJ 07310 Please visit our website for important disclaimers/disclosures regarding Knight’s products and services: http://www.knight.com/KnightEmailDisclaimer.html Please visit our website for important disclaimers/disclosures regarding Knight’s products and services: http://www.knight.com/KnightEmailDisclaimer.html -- Matthew O. Persico inline: image001.jpg
RE: ptkdb vs tkdb
Hi, As you may know, ptkdb uses perl/Tk. I - personally - moved to perl+Tcl/tk out from perl/Tk (many years ago) and never return back. For usage of debugger - I adopted ptkdb for perl+Tcl/Tk Now - if you're using perl/Tk - then do use ptkdb, if you're using perl+Tcl/Tk - then do use tkdb. During adoption, I greatly reduced the size of debugger, greatly improved (now it can debug autogenerated script of size 150k lines, for example)) Also I throwed away obsoleted technologies in ptkdb, but then I left it unfinished, in the middle. Maybe someday the work will be finished. maybe not. Please let us know if you have actual interest in it. Regards, Vadim. From: Persico, Matthew [mailto:mpers...@knight.com] Sent: Wednesday, January 16, 2013 7:06 PM To: 'aep...@users.sourceforge.net'; 'nob...@home.net'; 'v...@cpan.org' Subject: ptkdb vs tkdb Gentlemen, After a few years of being off in the wilderness of other languages I am returning to Perl. When searching for a piece of information about ptkdb, I encountered tkdb, some of whose documentation appears to be lifted right out of the ptkdb page. I also see that the tkdb page and AEP listed as an author. So, what’s the deal? Is tkdb the anointed successor to ptkdb? Or a sibling? Thanks, Matthew Persico, Vice President T 201 963 2525 mpers...@knight.com | www.knight.com [cid:078162611@17012013-113B] Knight Capital Americas LLC 545 Washington Blvd. | Jersey City, NJ 07310 Please visit our website for important disclaimers/disclosures regarding Knight’s products and services: http://www.knight.com/KnightEmailDisclaimer.html inline: image001.jpg
RE: proper CODE ref refcounting in Tcl::call (well, almost)
-Original Message- From: vadrer [mailto:m...@vadrer.org] On Sun, 2011-02-20 at 22:25 +, vadrer wrote: Some time ago (long ago) we tried to establish a way when CODE REFs created in Tcl::call would be properly refcounted, but then gave up. it appears that now I found a way how it could be done in a 99.999% clean way. I've just commited into repo Tcl.pm on github, https://github.com/gisle/tcl.pm/commit/fe4305492ee9fc845c992fa e13c91fa01da26cdb so following piece of code behaves correctly: and now I realised that in Tcl::eval sub we could put to %anon_refs hash just information based on __FILE__ and __LINE__ of invoked subroutine, just via 'caller' perl function, then CODE refcounting would be just fine, i.e. proper destroy of Tcl commands could be managed in time. all the same but key to hash is caller - all should be fine. ba. I commited new way https://github.com/gisle/tcl.pm/commit/bff6632139940e36468c912c2e8c92e28f00a4cc and then realized that this doesn't work correctly, due to combination of some reasons. Previous method worked pretty good, however. So ill revert latest change. And until anyone complaints incompatiibiities - I am going to roll a release soon, and this is quite good, as we'll have memory leaks fixed. (or those are not qualified as memory leaks?) Regards, Vadim.
RE: bind some said tcl to perl - all at once
Hi,
attached are the test for new convenience sub, and also small code to play
with, it is really simple.
So the proposed convenience sub becomes this way:
=comment
An interpreter method, export_to_tcl, takes a hash as arguments, which
represents named parameters, with following allowed values:
namespace = '...', - tcl namespace, where commands and variables are to
be created, defaults to 'perl'. If '' is specified - then global
namespace is used. A possible '::' at end is stripped.
subs = { ... },- anonymous hash of subs to be created in Tcl, in the
form /tcl name/ = /code ref/
vars = { ... },- anonymous hash of vars to be created in Tcl, in the
form /tcl name/ = /code ref/
subs_from = '...', - a name of Perl namespace, from where all existing
subroutines will be searched and Tcl command will be created for each
of them.
vars_from = '...', - a name of Perl namespace, from where all existing
variables will be searched, and each such variable will be tied to Tcl.
An example:
use strict;
use Tcl;
my $int = new Tcl;
$tcl::foo = 'qwerty';
$int-export_to_tcl(subs_from='tcl',vars_from='tcl');
$int-Eval('EOS');
package require Tk
button .b1 -text {a fluffy button} -command perl::fluffy_sub
button .b2 -text {a foo button} -command perl::foo
entry .e -textvariable perl::foo
pack .b1 .b2 .e
focus .b2
tkwait window .
EOS
sub tcl::fluffy_sub {
print Hi, I am a fluffy sub\n;
}
sub tcl::foo {
print Hi, I am foo\n;
$tcl::foo++;
}
=cut
sub export_to_tcl {
my $int = shift;
my %args = @_;
# name of Tcl package to hold tcl commands bound to perl subroutines
my $tcl_namespace = (exists $args{namespace} ? $args{namespace} : 'perl::');
$tcl_namespace=~s/(?:::)?$/::/;
# a batch of perl subroutines which tcl counterparts should be created
my $subs = $args{subs} || {};
# a batch of perl variables which tcl counterparts should be created
my $vars = $args{vars} || {};
# TBD:
# only = \@list_of_names
# argument to be able to limit the names to export to Tcl.
if (exists $args{subs_from}) {
# name of Perl package, which subroutines would be bound to tcl commands
my $subs_from = $args{subs_from};
$subs_from =~ s/::$//;
for my $name (keys %{$subs_from\::}) {
#print STDERR $name;\n;
if (defined {$subs_from\::$name}) {
if (exists $subs-{$name}) {
next;
}
#print STDERR binding sub '$name'\n;
$int-CreateCommand($tcl_namespace$name,
\{$subs_from\::$name}, undef, undef, 1);
}
}
}
if (exists $args{vars_from}) {
# name of Perl package, which subroutines would be bound to tcl commands
my $vars_from = $args{vars_from};
$vars_from =~ s/::$//;
for my $name (keys %{$vars_from\::}) {
#print STDERR $name;\n;
if (defined ${$vars_from\::$name}) {
if (exists $vars-{$name}) {
next;
}
#print STDERR binding var '$name' in '$tcl_namespace'\n;
local $_ = ${$vars_from\::$name};
tie ${$vars_from\::$name}, 'Tcl::Var', $int,
$tcl_namespace$name;
${$vars_from\::$name} = $_;
}
if (0) {
# array, hash - no need to do anything.
# (or should we?)
}
}
}
for my $subname (keys %$subs) {
#print STDERR binding2 sub '$subname'\n;
$int-CreateCommand($tcl_namespace$subname,$subs-{$subname}, undef,
undef, 1);
}
for my $varname (keys %$vars) {
#print STDERR binding2 var '$varname'\n;
unless (ref($vars-{$varname})) {
require 'Carp.pm';
Carp::croak(should pass var ref as variable bind parameter);
}
local $_ = ${$vars-{$varname}};
tie ${$vars-{$varname}}, 'Tcl::Var', $int, $tcl_namespace$varname;
${$vars-{$varname}} = $_;
}
}
# extra convenience sub, binds to tcl all subs and vars from perl tcl::
namespace
sub export_tcl_namespace {
my $int = shift;
$int-export_to_tcl(subs_from='tcl', vars_from='tcl');
}
I think this is good for inclusion.
I will change =comment/=cut to proper POD explanations afterwards.
Regards,
Vadim.
-Original Message-
From: Gisle Aas [mailto:gi...@activestate.com]
Sent: Thursday, January 20, 2011 12:07 AM
To: Konovalov, Vadim (Vadim)** CTR **
Cc: Jeff Hobbs; tcltk@perl.org
Subject: Re: bind some said tcl to perl - all at once
On Jan 19, 2011, at 17:47 , Konovalov, Vadim (Vadim)** CTR ** wrote:
First, I did not liked the name bind_... either.
create_commands obviously better.
(or maybe create_tcl_commands?)
However I think the idea could be extended to variables as
well, how do
you think, is it possible to leave
RE: Tcl::Tk Compatibility Updates for Perl/Tk
From: Michael Carman [mailto:mjcar...@mchsi.com] On 5/8/2010 10:23 AM, John Cerney wrote: If you [Vadim] don't think the changes fit your planned direction for the Tcl::Tk package, I was thinking that another option for the changes is to be released as a separate package (something like a new Tcl::pTk package ) Please don't. There are already three ways to use Tk from Perl. Adding a fourth is not desirable. Like it or not, Tk is competing for mindshare with Wx, Qt, Win32::GUI, etc. Fragmenting the Tk user base would be bad. Creating (more) confusion about which flavor of Tk bindings to use should be avoided. Yes, this problem is obvious. I thought that Tcl::Tk had started as a proof-of-concept that Perl/Tk API compatibility was possible so I'm a little surprised to hear Vadim rejecting that idea now. Personally, I'd like to see Perl/Tk compatibility happen, although I'd understand if some of the crustier Maybe these are implementation details what I really dislike, not the compatibility itself. Getting files from perl/Tk distro with modifications will make things unmaintainable. corners like Tix didn't make it in. Sometimes you have to sacrifice backward compatibility to keep moving forward. This Tix thing is a bit hard to decide on what to do. From one side, 100% compatibility requires it, probably with some modifications. On the other side, ordinary users just want things to behave on ActiveState's binaries, So, 'tix' should be included into 'tkkit.dll' - even if this is possible, it often will be not possible for ordinary users. I, for one, voting for larger tkkit.dll, and having a way to download such a file but having more packages included will be beautiful. Just for the sake of argument I'll throw out a couple of ideas. I'm not sure if either is practical. 1) Make John's changes available as a plug-in to Tcl::Tk, e.g. Tcl::Tk::Compat. 2) Usurp Perl/Tk. Release John's work as Tk version 805. I'm guessing that John's work requires changes to Tcl/Tk.pm, so the first option may not be feasible. The second option is more Changes to Tcl/Tk.pm are perfectly possible, maybe we should start with it. Maybe this is a way to go? So we'll change the way Tcl::Tk object is (a hash instead of array), and leave it as a single file. I am not absolutely happy with this idea, but, given that it is the only real stopper, let it be so :) Then, I believe, all other compatibility files could be optionally unpacked in a nearby directory/namespace and provide better compatibility, if needed. drastic and would require coordination with Slaven (and whoever else is applying patches to Tk). Given that Perl/Tk is maintenance only at this point and John's goal is to provide the same API, it would make more sense to call it a new version of Tk (with an all-new implementation) than to create a parallel distribution. Yes, we'll hardly convince perl/Tk people on such a reorganization, but - if they have little plans about Tk-8.5 and further 8.6 - then may be this is also a way to go. Regards, Vadim.
RE: Tcl::Tk Compatibility Updates for Perl/Tk
From: John Cerney [mailto:john.cer...@gmail.com] It looks like the changes I have made don't really fit into your vision for where the Tcl::Tk package should go. It probably makes more sense for me to release the changes as a separate package (probably named Tcl::pTk) as I mentioned earlier. I hope you can support that. I am not the only one who decides, and I think the idea of yet another same module would be considered as not a good one, unfortunately. I propose following approach - I'll change Tcl/Tk.pm to have a hash-based object, so it will be compatible with your other compatibility part, and then I will release it as next release. Then, we could decide on how to apply next. So this will hopefully allow to move forward. Regards, Vadim.
RE: Tcl::Tk Compatibility Updates for Perl/Tk
From: Jan Dubois [mailto:j...@activestate.com] FWIW, I agree with all the points here. I too would prefer that Tcl::Tk becomes as much as possible a Perl/Tk drop-in replacement. But since Vadim disagrees, I don't think there are many options left beyond forking Tcl::Tk to another namespace. :( I do not disagree... I also agree with all raised points, but I really like for the forrest of additional files to be optional. But I really think that reasonable compromise is perfectly possible The obvious namespace for a new/extended/incompatible implementation for Tk would be Tkx, but that is already taken... It is not clear to me that the new name has to be under the Tcl:: namespace; a top level namespace might still be appropriate. Maybe Tk2::, similar to Apache:: and Apache2::. I like Tk2 :) Regards, Vadim.
RE: Tcl::Tk Compatibility Updates for Perl/Tk
I haven't heard from you in a while and was wondering were you were at in reviewing and/or incorporating the changes I made to Tcl::Tk for perl/tk compatibility? Hi, indeed, I was planning with gathering your pieces, but eventually forgot about the problem, sorry. Right now I am in vacation trip till 13th of may w/o Internet. If you don't think the changes fit your planned direction for the Tcl::Tk package, I was thinking that another option for the changes is to be released as a separate package (something like a new Tcl::pTk package ) What do you think? I really like this solution - because it was my blue dream and real preference to have Tcl::Tk module really small - essentially one single PM file. But your solution has an unfortunate problem, though. Having yet another perl+tk solution will make people confused. They will not know what to select between Tkx, perl/Tk, Tcl::Tk and Tcl::pTk. But if users of this mailing list will see this as no-problem, I will greatly support this, and even will help you with some eventual patches of your new module. Sorry me once again, I really appreciate your effort, although I can not show you the code to support this my statement :) Best regards, Vadim.
FW: [rt.cpan.org #56721] CPAN build of Tcl fails on darwin x86_64
Hi, the bug report below contains the bug description and also a suggestion for solving the problem. Should we provide better libtclstub8.4.a for the mentioned platform? Does the binary coming with ActiveTCL 8.4/8.5 do the trick? Here it is: 'EOS'; From: onitake via RT [mailto:bug-...@rt.cpan.org] Sent: Monday, April 19, 2010 9:09 PM Subject: [rt.cpan.org #56721] CPAN build of Tcl fails on darwin x86_64 Subject: CPAN build of Tcl fails on darwin x86_64 Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=56721 Hello. I wanted to report that installing Tcl-0.98 from CPAN fails on Mac OS X 10.6, because Tcl-0.98/tcl-core/darwin-universal/libtclstub8.4.a doesn't contain code for all required architectures. Apple ships Snow Leopard with Perl 5.10.0, built as universal binary for x86_64, i386 and ppc. The default CPAN compilation options contain thus -arch x86_64 -arch i386 -arch ppc, for both compilation and linking. The included libtclstub8.4.a on the other hand has only an i386 and a ppc component. There is a /System/Library/Frameworks/Tcl.framework/Versions/8.4/libtclstub8.4.a that contains all three architectures, so I assume it would be better to use this instead and fall back to the included version when it's not available? Both Tcl and Tkx test and install flawlessly if I make a symlink to the system version of the library. Thanks Best regards, oni EOS Thanks in advance for a good advise, Vadim.
RE: Perl/Tkx equivalent to Perl/Tk's 'repeat'
And, are there any hints on how to translate the Tcl/Tk documentation to Perl/Tkx? For example, I don't know how to interpret the following and translate it into Perl/Tkx. tutorial on such interpreting, and hints are highly desired. pathName configure ?option? ?value option value ...? Query or modify the configuration options of the widget. If one or more option-value pairs are specified, then the command modifies the given widget option(s) to have the given value(s); in this case the command returns an empty string. If option is specified with no value, then the command returns a list describing the named option: the elements of the list are the option name, database name, database class, default value, and current value. If no option is specified, returns a list describing all of the available options for pathName. pathName is widget path (like .f.b2 etc), in Tkx this is ordinary widget. All other parameters are just strings on their own. (except for variable references and procedures, which are substituted from Perl to Tcl without you noticing it) So you should interpret pathName configure ?option? ?value option value ...? as $widget-configure(); or $widget-configure(option); or $widget-configure(option, value,option,value ...); Best regards, Vadim.
RE: Perl/Tkx equivalent to Perl/Tk's 'repeat'
Thank you Michael for your tip for implementing repeat. I had seen that posted elsewhere, but thought maybe there was a better way to do it. I implemented it successfully, but was hoping for a way to do it that didn't involve repeating the 'Tkx::after' command. Actually I was hoping to implement this command in Tcl, to gain better separation - let all tcl-related stuff happen inside tcl. Unfortunately only non-simple solutions are possible, as far as I see, due to lack of anonymous subroutines in Tcl. To notice, Perl/tk implementation of repeat is seemingly pure-perl. I would not mind having repeat convenience subroutine somewhere near. At least my two recent questions have caused perl.tcltk to go from Slow lists to Active lists :) feel free to participate in both user and development discussions of 3 related perl modules :) Best regards, Vadim.
RE: Drag-n-Drop in Perl/Tkx
So, is there any solution to getting Drag and Drop to work in Perl/Tkx, in Windows, with Perl 5.8.8? Is there a way to interface to Perl/Tk from Tkx? Drag and Drop in Perl/Tk is simple and I can do that, but I'd To the best of my knowledge, Perl/Tk does not allow extra-application drag-n-drop. Maybe I am wrong and not aware of something obvious for example I see on my system D:\perl584\site\lib\Tk\DragDrop\Win32Site.pm and also I see http://cpansearch.perl.org/src/SREZIC/Tk-804.028/dnd_demo in Tk distribution, but this seemingly deals with DND inside the same application, correct me if I am wrong. like to be able to use Tkx. I can't require all the engineers to download and install other packages, so I need a solution that uses 5.8.8. Or, is there a way to embed a package in my script, so that only I have to download it, but it is part of my script? IMO - yes, there are several ways to do that - you can put tkdnd files around and make your app to reach them, and also you can modify tkkit dll in a way that Jeff explained. Best regards, Vadim.
RE: Drag-n-Drop in Perl/Tkx
Hi Dave,
I'm not sure if tkdnd is in Perl, v5.8.8, binary build 822.
If it isn't
then I can't use it. I'm writing these scripts at work and everyone
needs to have the same version of Perl so that scripts that
run on my PC
also run on someone else's. And in the past the managers
were reluctant
to upgrade the version of Perl.
I think that tkdnd is not packaged with Activeperl distribution 5.8.8, and
also I very much doubt that it is distributed with other newer packages.
Jan Dubious and/or Jeff Hobbs have much better understanding on this packaging
than I, so maybe they comment?
I tried adding
Tkx::package_require('tkdnd'); and got an error, which is
what made me
think it might not be in this version.
that's not the version, but rather packaging.
OTOH taking tkdnd with your scripts is simplier than you think. Same
magnitude of complexity compared to distributing your application.
If tkdnd is not available, then I guess I'm stuck trying to
use Bwidget.
I saw a quote, which I think is yours, on an older post that says:
BWidgets is well-documented, so if you need inter-app DND,
then it will
suffice. But, you think that Bwidget DND will not allow DND with
external apps?
BWidgets is well-supported, but IMHO harder to use.
It is better WRT cross-platform, I guess, but lacks some features.
tkdnd does suffice me on both Linux and Windoz, and indeed it was not updated
for a long time already (maybe this is a good sign - no need to update :) )
I made the suggested change and there was no change.
I thought that all array references automatically converted to Tcl lists,
but obviously it was not the case.
What you really need - is Tkx::list function.
It is not documented, but you can derive it from following fragment of
perldoc Tkx:
q
Tkx::*foo*( @args )
Any other function will invoke the *foo* Tcl function with the given
arguments. The name *foo* first undergo the following substitutions
of embedded underlines:
foo_bar -- foo, bar # break into words
foo__bar -- foo::bar # access namespaces
foo___bar -- foo_bar # when you actually need a '_'
This allow us conveniently to map most of the Tcl namespace to Perl.
If this mapping does not suit you, use Tkx::i::call($func, @args).
This will invoke the function named by $func with no name
substitutions or magic.
/q
This function, and also Tkx::eval, and probably some other, deserve some
special mention and examples.
After even more reading of http://wiki.tcl.tk/16126; and given this
speculation, here is the working code snippet
code
use strict;
use warnings;
use Tkx;
my $text = abc;
Main(@ARGV);
exit(0);
sub Main {
local $Tkx::TRACE = 64;
Tkx::package_require('tile');
Tkx::package_require('BWidget');
eval { Tkx::tile__setTheme('xpnative'); 1 }
|| eval { Tkx::ttk__setTheme('xpnative'); 1 };
drawGUI();
Tkx::MainLoop();
}
sub drawGUI
{
our $t = Tkx::widget-new(.);
$t-g_wm_title(BWidgets Demo for Drag 'n Drop enabled buttons.);
$t = $t-new_ttk__frame( -name = '.f' );
$t-g_pack(qw '-fill both -expand true');
for my $i ( 1 .. 4 )
{
my $m = (qw' 0 Drag and Drop Demo ')[$i];
my $bb = $t-new_ttk__button(-name = $t.b$i,# auto-name is .b
.b2 .b3...
-image = Tkx::Bitmap__get( (qw'0 new file
copy redo ')[$i] ),
-text = $i.) $m,
-command = sub { print $m\n; });
$bb-g_pack;
}
enableDnD( map { $t.b$_ } 1 .. 4 );
$t-new_ttk__button(-text = Exit Demo,
-command = [ \Tkx::destroy, '.' ])-g_pack(qw'-padx 5
-pady 5');
my $entry = $t-new_entry(-width = 20, -textvariable = \$text);
Tkx::DropSite__register($entry,
-dropcmd = \dropcmdEntry,
-dropovercmd = \dropovercmdEntry,
-droptypes = Tkx::list(FOO_BAR_FLUFFY_TYPE,
Tkx::list('copy', '', 'move', '', 'link', '')),
);
$entry-g_pack(qw '-padx 5 -pady 5');
}
sub enableDnD
{
Tkx::DragSite__include('entry', 'FOO_BAR_FLUFFY_TYPE', 'B1-Motion');
for my $w (@_)
{
Tkx::DropSite__register($w,
-dropcmd = \dropButtonCmd,
-droptypes = Tkx::list(FOO_BAR_FLUFFY_TYPE, Tkx::list('copy',
'', 'move', '', 'link', '')),
);
Tkx::DragSite__register($w,
-dragevent = 1,
-draginitcmd = \dragInitCmd,
-dragendcmd = \dragEndCmd
);
}
}
sub dropButtonCmd
{
my @args = (@_);
print in dropButtonCmd\n;
for (my $i = 0; $i scalar @args; $i++)
{
print arg $i = '$args[$i]'\n if defined $args[$i];
}
return
RE: Drag-n-Drop in Perl/Tkx
The demo script works very nicely. Thank you!. But, we still can't drop a file onto the Entry box and have the file name appear (which is what *I* would really like). Is this a limitation of BWidgets or just the script? what do you mean by drag-n-dropping a file? Is it a file from external application (i.e. explorer)? If my guess is right, then the answer is - yes, BWidgets has limitation of not allowing DND of external application. I, personally, use file dropping into entry widgets using namely tkdnd. Best regards, Vadim.
RE: Drag-n-Drop in Perl/Tkx
Hi Dave,
sorry for delay in help.
There are several approaches to do DND, and the approach you've mentioned in
the very end of message
$interp-packageRequire('tkdnd', '2.0');
is different to BWidget's DND.
Moreover, the BWidget DND will not allow you DND with external applications
(i.e. windows explorer)
You need tkdnd for that.
I'll produce working example of tkdnd approach for Tkx soon, but you must
understand that you need to have tkdnd in your tcl/tk installation (this is
not always the case).
Now returning to your BWidget approach - I am new to BWidget DND, so I am nof
little use here.
I've looked into http://wiki.tcl.tk/16126 and found some errors in your code as
well.
your
return (text, (copy), $data);
should be
return [text, copy, $data];
or something similar - you should use array refs when transfering to Tcl lists.
I'll provide mnore information when I'll get working code, but, to my taste,
BWidget DND isn't obvious., compared to tkdnd discussed earlier.
Sorry for little information so far :)
Best regards,
Vadim.
With some help from www.perlmonks.org
BLOCKED::http://www.perlmonks.org , I have the following.
It handles
the drag part of a widget in the window, but the drop part doesn't do
anything. I ultimately want to be able to drag a file from windows
explorer and have the filename (and path) recognized in the widget.
Can't get 'drop' to work in Perl/Tkx. Any help would be appreciated.
Dave
#!/usr/bin/perl --
use strict;
use warnings;
use Tkx;
my $text = abc;
Main(@ARGV);
exit(0);
sub Main {
local $Tkx::TRACE = 64;
Tkx::package_require('tile');
Tkx::package_require('BWidget');
eval { Tkx::tile__setTheme('xpnative'); 1 }
|| eval { Tkx::ttk__setTheme('xpnative'); 1 };
drawGUI();
Tkx::MainLoop();
}
sub drawGUI
{
our $t = Tkx::widget-new(.);
$t-g_wm_title(BWidgets Demo for Drag 'n Drop enabled buttons.);
$t = $t-new_ttk__frame( -name = '.f' );
$t-g_pack(qw '-fill both -expand true');
for my $i ( 1 .. 4 )
{
my $m = (qw' 0 Drag and Drop Demo ')[$i];
my $bb = $t-new_ttk__button(-name = $t.b$i,# auto-name
is .b .b2 .b3...
-image = Tkx::Bitmap__get( (qw'0
new file copy redo ')[$i] ),
-text = $i.) $m,
-command = sub { print
$m\n; });
$bb-g_pack;
}
enableDnD( map { $t.b$_ } 1 .. 4 );
$t-new_ttk__button(-text = Exit Demo,
-command = [ \Tkx::destroy, '.'
])-g_pack(qw
'-padx 5 -pady 5');
my $entry = $t-new_ttk__entry(-width = 20, -textvariable =
\$text);
Tkx::DropSite__register($entry,
-dropcmd = \dropcmdEntry,
-dropovercmd = \dropovercmdEntry,
-droptypes = {text, {copy, none}});
$entry-g_pack(qw '-padx 5 -pady 5');
}
sub enableDnD
{
for my $w (@_)
{
Tkx::DropSite__register($w,
-dropcmd = \dropButtonCmd);
Tkx::DragSite__register($w,
-dragevent = 1,
-draginitcmd = \dragInitCmd,
-dragendcmd = \dragEndCmd);
}
}
sub dropButtonCmd
{
my @args = (@_);
print in dropButtonCmd\n;
for (my $i = 0; $i scalar @args; $i++)
{
print arg $i = '$args[$i]'\n if defined $args[$i];
}
return abc;
}
sub dragInitCmd
{
my @args = (@_);
print in dragInitCmd\n;
for (my $i = 0; $i scalar @args; $i++)
{
print arg $i = '$args[$i]'\n if defined $args[$i];
}
my $data = \Button . $args[3] . \;
return (text, (copy), $data);
}
sub dragEndCmd
{
my @args = (@_);
print in dragEndCmd\n;
for (my $i = 0; $i scalar @args; $i++)
{
print arg $i = '$args[$i]'\n if defined $args[$i];
}
}
sub dropcmdEntry
{
print dropcmdEntry\n;
return entry;
}
sub dropovercmdEntry
{
print dropovercmdEntry\n;
}
When I run the script and drag one of the buttons around, I get
something like the following, but I can't seem to get the
drop commands
to ever fire.
Tkx-1-0.0s-dnd2.pl-13: package require tile
Tkx-2-0.1s-dnd2.pl-14: package require BWidget
Tkx-3-0.1s-dnd2.pl-15: tile::setTheme xpnative
Tkx-4-0.1s-dnd2.pl-24: wm title . {BWidgets Demo for Drag 'n Drop
enabled buttons.}
Tkx-5-0.1s-dnd2.pl-26: ttk::frame .f
Tkx-6-0.1s-dnd2.pl-27: pack .f -fill both -expand true
Tkx-7-0.1s-dnd2.pl-35: Bitmap::get new
Tkx-8-0.1s-dnd2.pl-35: ttk::button .f.b1 -image image1 -text
{1.) Drag}
-command perl::callback
Tkx-9-0.1s-dnd2.pl-36: pack .f.b1
Tkx-10-0.1s-dnd2.pl-35: Bitmap::get file
RE: New Tcl::Tk to follow?
From: Michael Carman [mailto:mjcar...@mchsi.com]
jeff j...@roqc.no wrote:
could someone post a short blurb of what dlls ( dylibs for Aqua)
would be required for packaging Tcl::Tk stand-alones with perlapp
or PAR?
I've packaged Tkx apps using PAR. Tcl::Tk apps should work
the same way. You need to explicitly bundle Tcl.dll and
tkkit.dll when invoking pp. For example:
thank you for sharing your experience.
-l C:/Perl/lib/auto/Tcl/Tcl.dll
-l C:/Perl/lib/auto/Tcl/tkkit.dll
Unfortunately, it's not quite that simple due to the way PAR
unpacks shared libraries. You need to modify your script to
detect when it's running under PAR and tell the Tcl module
where to find the libs:
use File::Spec::Functions;
BEGIN {
if (exists $ENV{PAR_PROGNAME}) {
use Config ();
$ENV{PERL_TCL_DL_PATH} = catfile(
$ENV{PAR_TEMP},
'tkkit.' . $Config::Config{dlext}
);
}
}
I package differently, but, essentially, I also have some PAR detection for
Tcl.pm
Michael, your approach is good,
but I think the better way is to update both PAR and Tcl.pm parts of the
process, so your fix will not be necessary.
I think, that PAR should bundle C:/Perl/lib/auto/Tcl/Tcl.dll. If it do not -
it should be fixed then.
Also, adding tkkit.dll could also be done on PAR side, but there is a problem
of detecting whether tkkit.dll is actually used.
Other missing parts could become part of Tcl.pm.
Regards,
Vadim.
RE: [tcltk-perl] Newest version
I've now synced up the Git repo with what was in your release http://github.com/gisle/tcl.pm/commits/0.98. thanks! I wonder what to do about the 'ChangeLog' file that's not maintained any more. Should we just delete it or replace it with the 'git log' output? Yes, I think both approaches are just fine. Tip: For the next release you should try to create the dist package with a more recent version of MakeMaker. This is needed for the additional meta-data to make it into the META.yml file. This will create links to the repository and mailing list from the search.cpan.org/dist/Tcl page. That page would then also say something better than Unknown about the license. Yes, I saw the warning message about LICENSE keyword. I used perl 5.8.8, whereas I had choice of using both 5.10.0 and 5.10.1. Thanks for clarification. Best regards, Vadim.
RE: [tcltk-perl] Newest version
Which reminds me that I would like to see a refresh of the CPAN module. I went off doing other stuff and forgot about this. Do you mind if we just make the current HEAD in the http://github.com/gisle/tcl.pm repo the official Tcl.pm-0.98? I think it's good to go (still needs to update Changes). thank you for your help, I've just made the release. Unfortunately, we've dropped the 5.6 support - is there anything in update that was really a feature of 5.8? And I think some 65% of documentation could be just dropped. Ok, we'll see how it will be :) Best regards, Vadim.
RE: [tcltk-perl] New Tcl::Tk to follow?
I see the new Tcl module is released to CPAN. Will there be a 0.98 of Tcl::Tk following ? I hope so, but now some large change was developed by John Cerney, which brings a much better perl/Tk compatibility, but at the same time makes the module rather large. So it will take few days to make some decisions. Essentially, Tcl::Tk it was just one single pm, and there was some good in this. Now I think that Tcl::Tk should be split into Tcl::Tk-mini, which brings just perl/Tk syntax, and all remaining part, which brings full perl/Tk compatibility. Also could could someone post a short blurb of what dlls ( dylibs for Aqua ) would be required for packaging Tcl::Tk stand-alones with perlapp or PAR ? Any gotchas with packaging this module with TclTk ? I do Tcl::Tk+PAR, but my approach is non-standard, because I link tcl/tk some of binaries directly into the shared library of Tcl CPAN module. I do not know details of ActiveState's tkkit.dll approach, maybe its easier for PAR? Regards, Vadim.
RE: Tcl::Tk Updates Ready for Release
As you found, the versions of all the .pm files should be cleaned up. This was something I had overlooked. Some of these versions are left over from the perl/tk version. Probably should make all of them match the main version of the Tcl::Tk package. okay, we'll decide that later, after more cleanups. I put the bitmap files (i.e. the xbm, xpm, etc files) in the Tcl/Tk directory, because perl/tk puts them in a similar place. Bitmap files for perl/tk end up in the Tk directory after installation. They could possibly be moved to a bitmaps directory under the Tcl/Tk directory, as long a Tcl::Tk-findINC can still find them. we are not obliged to follow bad designs. findINC is bogus and it should not be a reason for anything otherwise inconvenient. I not sure if the perl/tk files can be separated out from the Tcl::Tk files. Most aren't direct copies of the perl/tk files. The perl/tk files were used as a starting point, and then hand-edited to get to work with Tcl::Tk. yes, I understand that, but something should be done, because the problem is not non-existent. If we separated out the perl/tk files, it could cause some confusion in converting from perl/tk code to Tcl::Tk. For example, the Font.pm package is currently in the Tcl/Tk directory, so it gets used with a use Tcl::Tk::Font, which is very similar to the perl/tk sytax of use Tk::Font. If the Font.pm package was moved to another directory (like Tcl/Tk/perltk), then you would have to use use Tcl::Tk::perltk::Font. Would the Tcl::pTk::Font be reasonalble alternative? This may be problematic with CPAN indexing, I wonder, are there any modules that do something like this? On the one side, the Tcl name space is likely to be free for our usage, but on the other hand such a pollution to another namespace could be prohibited. I wonder, is it at all possible? Surely, there are yet other alternatives. Maybe a better way of identifying the perl/tk files would be to put a special text header in them (e.g. Imported from perl/tk ###'), that way you could grep for some special text, and get a list of perl/tk-derived files. well, IMO, if all else fails, this would be better than nothing. Other alternative to call such derived files somehow recognizable. But leaving all in one large heap is not the way to go. Also, what the mktransgif.tcl file for? Its not even in the Manifest. It doesn't do anything. Some overactive copy/paste on my part :) . I just removed it from svn. thanks. keep moving forward in this direction :) :) Actually Tcl::Tk was just one single file, plus some 2 .pm files which could be avoid. Honestly, I want to avoid such a mess that currently is in perl/Tk. And, IMO, all versions of all files should be better thought. I see that Tcl::Tk version didn't change, and Tcl::Tk::Widget does not have version at all. Agreed. All .pm files need a version. Same as the version of the overall Tcl::Tk package IMO. Alternatively, a version number derived from svn. I guess you're right. May be there should be something like $Tcl::Tk::Widget::VERSION = $Tcl::Tk::VERSION; ? just a thought. But still, why you really put that module into separate file? It is surely must be loaded in 100% cases. May be it should be returned back? just another thought, maybe you're right moving it outside. Need to decide. Regards, Vadim.
RE: Tcl::Tk Updates Ready for Release
Hi Vadim, After much bug-fixing, I think the updated Tcl::Tk package is ready for a release. As we talked a few months ago, the changes make Tcl::Tk almost 100% compatible with perl/tk syntax. All changes have been checked in at http://code.google.com/p/perl-tcltk Hi John, I very much glad for the much work you've done, especially if you got full or almost-full compatibility. What I am currently not understanding with your version - is what files are and what are they came from. Many perl/Tk-derived files together in same directory with Tcl::Tk files will produce a mess. For example in Configure.pm I see = package Tcl::Tk::Configure; use vars qw($VERSION); $VERSION = '4.008'; # $Id: //depot/Tkutf8/Tk/Configure.pm#8 $ = This 4.008 is obviously poorly updated version in perl/Tk land, which is okay with me, but is it possible to invent a way to place all those files into their directory? Especially all these xbm, xpm and gif files If perl/Tk and Tcl::tk files are distinguished, it will be easier to check for updates from perl/Tk also. Also, what the mktransgif.tcl file for? Its not even in the Manifest. And, IMO, all versions of all files should be better thought. I see that Tcl::Tk version didn't change, and Tcl::Tk::Widget does not have version at all. I have tested on Redhat Enterprise, Ubuntu 8.04, and Windows XP and everything appears to work. I have also updated the documentation. I can help with the upload to CPAN, if needed. I am familiar with the process. Again, thank a lot for the great work. I'll look into the code in closer details. Regards, Vadim.
RE: Drag and Drop in Tkx
From: Laurence Anthony [mailto:anthony0...@gmail.com]
The next thing to do would be to convert the Tkdnd script
that Vadim sent
earlier into Tkx syntax:
#the line below is just creating a widget - no dnd consideration
pack [entry .frTop1.current_dir -textvariable
ptclv_current_dir] -side left
-fill x -expand 1
# and this actually makes DND work
tkdnd::drop_target register .frTop1.current_dir *
bind .frTop1.current_dir Drop:DND_Files {
set ptclv_current_dir [lindex %D 0]
ptcl_refresh
}
IMHO this part of code should be left in plain tcl, but a Tkx method should be
created, which will take a widget and a subroutine ref, which will be invoked
for DND operation, maybe in a separate package. Tkx::Tkdnd, which also invokes
package require tkdnd at a proper time.
I vote for a bit more pure-tcl/tk eval code in Tkx, but maybe you're right, and
exactly opposite POV takes place, which is also perfectly okay with me :)
TIMTOWTDI
Here, I'm not familiar with the Drop:DND_Files code, but
the rest is
probably OK (although I worry about the syntax for the set command
set ptclv_current_dir [lindex %D 0]
I feel a complete novice here even though I've written
several large Tkx
apps. I worry that others (especially coming from PerlTk)
will be completely
lost.
I've shared the Tcl::Tk version of code for this snippet, which could make
PerlTk people think that they see a familiar code, but actually this isn't
absolutely so :)
Regards,
Vadim.
RE: Drag and Drop in Tkx
Here's a new thread with a suggestion to include the results
in the Tkx
documentation (following an earlier thread on documentation issues).
How do we do drag and drop in Tkx? Does anyone have a simple
script that
demonstrates this for, say, a listbox widget that allows
dropping in file
names from folders on the desktop (in Windows, Mac, and
Linux)? Or, a text
widget that allows dropping in the contents of files from a
simple text
file.
I have no Tkx usage, but I'll share my more generic Tcl.pm way.
For intra-application DND, you need to use widgets that support that.
For example, BWidgets support this, so may be we could easily develop a Tkx
example with BWidgets DND.
In my applications I use another way.
I use tkdnd http://wiki.tcl.tk/2768, which allows me dropping items from
external applications.
It happened this way that I am using two ways of doing DND in my applications,
both ways based on the same engine under the hood.
The newer way, which I currently prefer, involves some pure-tcl code, which I
mostly copy-pasted from eslewhere..
Here is pure-tcl code that I feed to tcl/tk:
package require tkdnd
#the line below is just creating a widget - no dnd consideration
pack [entry .frTop1.current_dir -textvariable ptclv_current_dir] -side left
-fill x -expand 1
# and this actually makes DND work
tkdnd::drop_target register .frTop1.current_dir *
bind .frTop1.current_dir Drop:DND_Files {
set ptclv_current_dir [lindex %D 0]
ptcl_refresh
}
...
EOF
Then I even do not bother about widget .frTop1.current_dir - it has DND, binded
to variable so I do not even expose widget itself to my perl program.
I do expose other widgets, however.
This approach will suit for Tkx module as well - it is front-end syntax
agnostic.
Another, elder way, which I do not prefer anymore, uses Tcl::Tk syntax, and
technically it is absolytely the same.
$interp-packageRequire('tkdnd','2.0');
my $w_curdir =
$frame-Entry(-textvariable=\$var)-pack(-side='left',-expand=1,-fill='x');
$interp-tkdnd__drop_target(register = $w_curdir, *);
$w_curdir-bind('Drop:DND_Files', \\'D', sub {
my (undef,undef,undef,$data) = @_;
($$cwd_r) = $interp-SplitList($data);
});
Even in Tcl, this seems to be a poorly documented issue.
Things are not that bad if you know where to search :)
BWidgets is well-documented, so if you need inter-app DND, then it will suffice.
Usually Jeff tell us about which packages are poorly supported and which are
not, and IIRC he said BWidgets are o-kay to use :)
BR,
Vadim.
RE: Are multiple mainwindows possible?
From: Michael Carman [mailto:mjcar...@mchsi.com]
Does Tkx (or perhaps it would be Tcl.pm) support multiple mainwindows?
This doesn't complain, but even though $x and $y have different
addresses they refer to the same Tk widget.
my $x = Tkx::widget-new('.');
my $y = Tkx::widget-new('.');
That's not surprising since they have the same name. Methods like
_parent() and _kid() exploit this to retrieve the widget reference
from the Tcl name. Giving $x and $y different Tcl names doesn't appear
to be an option, either. Most of my attempts ended in bad window path
name errors. While there are lots of examples of using '.'
as the name
of the root window and it appears to be a requirement, the
documentation
never actually explains it.
It looks like multiple mainwindows are not possible, in which
case I can
safely ignore that aspect of the Tk behavior. Is this true?
In my vision, in tcl/tk world there is only one mainwindow (a toplevel with
path '.'), but this is per interpreter.
With tk-enabled Tcl.pm you could do
my $interp2 = $interp1-interp('create');
and have another mainwindow for $interp2.
As it seems to me, the Tkx package creates only one tcl interpreter within
Tkx::i package and does not expose it to the user. So it seems to me that
seconf interpreter is not possible for Tkx, but could be possible with a minor
modifications to Tkx.
On the contrary, in Tcl::Tk any widget has interp method, which gives you an
instance to widget's interpreter, so it is possible to create another one, but
I never used that feature, may be it is never needed...
Which makes me wonder - is my understanding true, that in Tkx a user is not
allowed to do tcl/tk's evals?
IMO, this is a really nice feature! Really powerful!
Best regards,
Vadim.
RE: Tcl.pm repo
From: Gisle Aas [mailto:gi...@activestate.com] The last public source repository is at tcltkce.cvs.sourceforge.net (sf) and it contains some commits from Jeff Hobbs, those are the latest. It comes back to me now. I would have to research what it takes to restore access to that repo. I would be much happier if we could move away from CVS. Git is my preference nowadays. My suggestion is to convert the old CVS repository to a Git repo and then host the official mirror on Github or Gitorious. I would be 1% happier with googlecode, but, given that you'll move the repository somehow, let it be your choice, I'm fine with either Github or Gitorious. Will you please take care moving both Tcl and Tcl::Tk at once there? (and may be Tkx also?) Thanks in advance, Vadim.
RE: Tcl.pm repo
-Original Message-
From: Gisle Aas [mailto:gi...@activestate.com]
Sent: Tuesday, September 01, 2009 10:43 PM
To: Konovalov, Vadim (Vadim)** CTR **
Cc: Vadim Konovalov; tcltk@perl.org
Subject: Re: Tcl.pm repo
On Sep 1, 2009, at 8:53 , Konovalov, Vadim (Vadim)** CTR ** wrote:
From: Gisle Aas [mailto:gi...@activestate.com]
The last public source repository is at
tcltkce.cvs.sourceforge.net (sf) and
it contains some commits from Jeff Hobbs, those are the latest.
It comes back to me now. I would have to research what it takes to
restore access to that repo. I would be much happier if we
could move
away from CVS. Git is my preference nowadays.
My suggestion is to convert the old CVS repository to a
Git repo and
then host the official mirror on Github or Gitorious.
I would be 1% happier with googlecode, but, given that you'll move
the repository somehow, let it be your choice, I'm fine
with either
Github or Gitorious.
Will you please take care moving both Tcl and Tcl::Tk at
once there?
(and may be Tkx also?)
First attempt at converting the CVS repo from sourceforge has
now been
performed. You can investigate and grab the result from:
http://github.com/gisle/tcl.pm/commits/master
The tagging in the CVS repo appear to be lacking (the only tags that
appeared was Tcl-0-{72,75,85}) so I will spend a little time trying
verify the converted result and try to recreate some tags
matching the
most recent CPAN releases at least.
It seems like the history of the CVS repo starts with Author: Jeff
Hobbs je...@activestate.com; Date: Mar 22 2004; initial import of
Vadim's Tcl-0.72 Perl/Tcl bridge module into sf cvs. If you happen
to have a repo of earlier history, then we could add that to the GIT
repo as well.
very much thanks!
Will I be able to commit there? (I've just created my new user vadrer)
I wonder - are you really converting repositories, or just importing the
latest source snapshot?
It seems to me that we could live without a previous history of changes.
If you want I'll convert the TclTk repo as well.
may be just importing stuff would be enough.
Vadim.
RE: [Fwd: Re: trouble with Tcl::Tk]
Jeff Hobbs wrote: Brian Bevins wrote: So Tcl.so wants to implicitly load the same libtcl8.4.so as our tclsh. Somehow tclsh is making TclpRealloc available to BLT, but Tcl.so doesn't unless I explicitly load libtcl8.4.so after it. OK, and the solution is then to use a --usestubs build Tcl.so then, correct? This really should be the default. Yes, --usestubs plus explicitly specifying LIB_RUNTIME_DIR makes everything work as expected. --usestubs does not appear to be the default. Line 16 of Makefile.PL: my $usestubs = 0; And --usestubs by itself causes the use of some sort of local copy of tcl-core. Everything I have tried besides BLT seems to work with the defaults (without --usestubs). I'm glad the issue is resolved, just for the records, BLT on Windows w/o stubs is fine. I guess we'll include a fix based on your experience for Tcl with BLT on linux. Also, I think I'll package some 'snit' version for Tcl::Tk and release both packages within may be a week, so you'll not have trouble with downgrading to 0.92 version. BR, Vadim.
RE: utf-8 support for Tkx ActiveStatePerl (5.8.8) under Windows Vista
From: Gisle Aas [mailto:[EMAIL PROTECTED] Don't use Unicode::String as it will give you encoded utf8, which is not what Tkx wants. Yes, Unicode::String is long obsoleted by perl internal encoding support and by Encoding module But even after doing this I still see some Chinese(?) letters in the listbox, not the Cyrillic I expected. I see cyrillic but I do not know meaning of this word - its abracadabra :) Fun aside, I heavily use different encodings in Tk and do not experience encoding problem. (I saw no chinese chars in attached scripts either, although I sometimes use chinese chars in my applications) BR, Vadim.
why 'use overload' in in Tcl?
Dear all, In my needs to reduce number of dependant modules, I came into use overload line. Why its here? its used in following lines: = package Tcl::List; use overload '' = \as_string, fallback = 1; package Tcl::Var; It unfortunate because its usage slurps other 4 modules: Carp.pm=e:/perl584/lib/Carp.pm Exporter.pm=e:/perl584/lib/Exporter.pm overload.pm=e:/perl584/lib/overload.pm warnings.pm=e:/perl584/lib/warnings.pm warnings/register.pm=e:/perl584/lib/warnings/register.pm Do Tkx need it? (Tcl::Tk does not need it) BTW I noticed that replacing use DynaLoader to use XSLoader is win-win sutiation, because all we need is to load Tcl.dll, which do not require heavy-load of DynaLoader. I'll commit my change to XSLoader, but I need to ask overload also... BR, Vadim.
RE: ROText strange behavoir
I have found very strange behavior of ROText in Tcl::Tk. 1. Selection (tag 'sel') works halfway and differently on each platform: It only work via mouse (not via arrow keys) and it is visible only on Linux. On Mac and Windows, selection is there, but invisible. If I understand the situation correctly, this is a problem with Text widget rather than particular ROText. I asked in ActiveTCL list: http://aspn.activestate.com/ASPN/Mail/Message/activetcl/3172029 (but I do not see replies, neither Jeff's, nor my reply to his reply -- strange) On windows, Text selection is hidden when widget loses focus, and this is frustrating: even when I use scrollbars to scroll the text, selection disappears. This is how Jeff explained to me: ==quote=== Yes, this is something that is platform dependent (only X11 maintains selection) and is actually hard-coded in at the C level. I would favor changing this, but it is also something that is more theme-driven. The newer themed widgets have a sense of state, which allows for focus and !focus selected colors. ==end-of-quote=== As I currently see, Linux behaviour is better WRT this, but Windows behaviour is just needs to be fixed. Very same behaviour within perl/Tk. I was hoping Tile package will provide Text with configurable themed selection, but I am out of luck. 2. Key bindings (e.g. $t-bind( Key-j, \TagAsPerson );) do not work (respective tagging functions work fine via buttons). which buttons do you mean? I am suspicious, possible that binding is ignored due to -state=disabled option? 3. On Windows both 1. and 2. are true when I load my Tcl::Tk application alone. However as soon as I load any Perl::Tk or Tkx application (it does not have to contain an ROText widget) when Tcl::Tk one is running, Tcl::Tk ROText starts behaving differently (better for me, actually!): -- selection becomes visible -- most key bindings start working -- cursor (still invisible) can be placed via mouse click -- selection via arrows works, but only horizontally. Vertical arrows do nothing. Just now I have found this modification also happens when I have no selection and try to create a tag. I get Tcl error and then it works as described above, no other application loading necessary. Do you have example of code handy, to demostrate the behaviour? Why is this happening? and more importantly: How can I make Tcl::Tk ROText behave this way by default on all systems without the strange magic? I need sellection, cursor and (all) key bindings working consistently everywhere. Speaking on difference between perl/Tk ROText and Tcl::Tk ROText, they are implemented differently: set of predefined bindings in perl/Tk, and -state='disabled' in Tcl::Tk's case. We can reimplement ROText for Tcl::Tk, if this will actually cure the situation... Speaking about selection. As long as Tcl::Tk ROText is nothing more but Text with -state='disabled', plus 2 overridden methods, then things with consistent selection will not be fixed until Tk's problem. Best regards, Vadim.
Tcl.xs 0.89 change
Dear all, I hope no-one will be against following addition, which will go into CVS soon: --- Tcl.xs.orig 2006-05-23 13:31:19.0 +0400 +++ Tcl.xs 2006-07-14 20:01:05.273768000 +0400 @@ -1315,6 +1315,46 @@ Tcl_CreateObjCommand(interp, ::perl::Eval, Tcl_EvalInPerl, (ClientData) NULL, NULL); +#ifdef HAVE_TKINIT + +void +Tk_Init(interp) + Tcl interp +CODE: + Tk_Init(interp); + +#endif + +#ifdef HAVE_MEMCHANINIT + +void +Memchan_Init(interp) + Tcl interp +CODE: + Memchan_Init(interp); + +#endif + +#ifdef HAVE_TRFINIT + +void +Trf_Init(interp) + Tcl interp +CODE: + Trf_Init(interp); + +#endif + +#ifdef HAVE_VFSINIT + +void +Vfs_Init(interp) + Tcl interp +CODE: + Vfs_Init(interp); + +#endif + int Tcl_DoOneEvent(interp, flags) Tcl interp This allows for any person (me, for example :) to pass parameters to Makefile.PL , and this allows for creating Perl+Tcl/Tk extension with all Tcl and Tk etc C code built into perl extension. So I have 1.6 Mbyte DLL and with a help of a little trick all TCL scripts inside some ZIP archive, which much easier to be PPM-ed... All helper scripts will be available soon. BR, Vadim.
RE: Perl Tcl module 0.88 problem
I've downloaded and installed the Tcl Perl module at
http://search.cpan.org/~vkon/Tcl-0.88/Tcl.pm that you
mantain/author (as it
can be
read in the README that comes with the .tar.gz) and I'm finding some
problems. If you are not the rignt person to deal with this
issue, please
tell me where should I address the question (online
documentation, mailing
I am right person, but using address tcltk@perl.org is even better - this is
proper discussion mailing list.
The problem is that TCL packages I usually load without
problems using tclsh
cann't be loaded from the TCL interpreter created from Perl.
For example,
using tclsh console to load a package goes right:
you need to call Init method of interpreter.
See my win32 session:
E:\perl -MTcl -we $i=new Tcl;$i-Eval('package require Tix')
can't find package Tix at -e line 1.
E:\perl -MTcl -we $i=new Tcl;$i-Init;$i-Eval('package require Tix')
E:\perl -MTcl -we $i=new Tcl;$i-Init;$i-Eval('package require Tixf')
can't find package Tixf at -e line 1.
If instead of Tcl you'll use Tcl::Tk interpreter, then it is more prepared:
perl -MTcl::Tk -we $i=new Tcl::Tk;$i-Eval('package require Tix')
BR,
Vadim.
RE: Scrolled Tk Pane through Tcl
I don't know Tcl, this was kind of attempt to find how easy/difficult it is to access Tk/Tcl library through Tcl::Tk and also to find a workaround when Tk::Text module with Perl 5.8.7 fails to work (non ascii characters are distorted). When I added another chunk of code to my original snippet, I had to disable sticky option in the Scrolled method because of Tcl error 'unknown option -sticky at ...' Another error was Tcl error 'invalid command name ScrollableFrame::ToolBar at ...'. I suppose there is no support for Tk::ToolBar in Tcl::Tk as well. So, if you'll post here more complete GUI part of your code, I can expand perl/Tk support in Tcl::Tk module to cover your widgets usage. But generally - when writing new programs with Tcl::Tk you will not face this problem, but your widget library will be larger from the very start. Regarding overriding -scrollbars option I'm not sure if there's anything similar in ScrollbarFrame, I'd like to have scrollbars optional. sure they will be supported in next Tcl::Tk version. Vadim.
