tcltk-perl

[tcltk-perl] why autoloading in Tcl/Tk do not work from Tcl::Tk?

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

Does anyone has an idea why autoloading does not fully functioning when
Tcl/Tk is used from Perl?

As an example,
     $interp->call('tk_setPalette', $color);
does not work: it fails to find tk_setPalette procedure

But following works:
     $interp->Eval('tk_setPalette '.$color);

and once that code is executed previous piece of code also works properly.

Code for that function lives in a file lib/tk8.4/palette.tcl

Same thing for tk_optionMenu

Best regards,
Vadim.

Re: [tcltk-perl] why autoloading in Tcl/Tk do not work from Tcl::Tk?

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

Vadim Konovalov wrote:
> Does anyone has an idea why autoloading does not fully functioning when
> Tcl/Tk is used from Perl?
> 
> As an example,
>      $interp->call('tk_setPalette', $color);
> does not work: it fails to find tk_setPalette procedure
> 
> But following works:
>      $interp->Eval('tk_setPalette '.$color);
> 
> and once that code is executed previous piece of code also works properly.

The eval goes through a different path that will invoke the
unknown mechanism (which handles auto-loading), whereas the
icall function as written only ever invokes a command if it
already exists - it does NOT allow for autoloading.

This is the crux of the difference between the pre-existing
icall function and the alternative that I wrote (but is not
used by default).  See the comments in the C code.  Perhaps
you do want to use my icall function by default instead?

Other things you miss are command tracing and async checks.
The current icall function to the lowest level to make its
calls, which may be desired ... but perhaps we should make
them 2 alternate functions, with the default 'icall' being
my alternative function, and 'invoke' being the current
'icall'?

BTW, I would also like to see a core 'catch' function, for
handling Tcl calls that may well error in a more perl-ish
integrated way.

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

Re: [tcltk-perl] why autoloading in Tcl/Tk do not work from Tcl::Tk?

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

> > Does anyone has an idea why autoloading does not fully functioning when
> > Tcl/Tk is used from Perl?
> >
> The eval goes through a different path that will invoke the
> unknown mechanism (which handles auto-loading), whereas the
> icall function as written only ever invokes a command if it
> already exists - it does NOT allow for autoloading.

Thanks for explaining.

'unknown' mechanism explains all.

>
> This is the crux of the difference between the pre-existing
> icall function and the alternative that I wrote (but is not
> used by default).  See the comments in the C code.  Perhaps
> you do want to use my icall function by default instead?

I see your comment, and I think "call" from Tcl.pm should invoke your
version of "icall"

>
> Other things you miss are command tracing and async checks.
> The current icall function to the lowest level to make its
> calls, which may be desired ... but perhaps we should make
> them 2 alternate functions, with the default 'icall' being
> my alternative function, and 'invoke' being the current
> 'icall'?

Let's do this way...
Will you implement this change please?

Vadim.

Re: [tcltk-perl] why autoloading in Tcl/Tk do not work from Tcl::Tk?

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

Vadim Konovalov wrote:

> I see your comment, and I think "call" from Tcl.pm should invoke your
> version of "icall"
> 
> 
>>Other things you miss are command tracing and async checks.
>>The current icall function to the lowest level to make its
>>calls, which may be desired ... but perhaps we should make
>>them 2 alternate functions, with the default 'icall' being
>>my alternative function, and 'invoke' being the current
>>'icall'?
> 
> 
> Let's do this way...
> Will you implement this change please?

OK, I'll have this in by tomorrow.

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

[tcltk-perl] CPAN release, version 0.80

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

Dear all,

I did CPAN release.
Thank you all for providing great help and support.

I did not finished all what I planned to, but hopefully this release mostly
finished.
I plan to make another release quite soon, because at current week I'll have
quite many moments for developing module.

Remarkably, I replaced files in tk-demos directory to files from perlTk
distribution.
Some demos run with no modifications, some must be adopted, and many could
be used to improve perlTk compatibility.
It will be great if those files will receive fixes, so updates here are very
welcomed.

Best regards,
Vadim.

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

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

Still, I do not know how to make for CPAN indexer not to check for files in
tk-demos and demos directories

Does anyone has a cure to the problem?

Vadim.

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

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

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

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

I notice that the new META spec now defines an index: and no_index: section,
and that private: is considered deprecated.  I don't know if index: and
no_index: are already implemented; you may have to do some research, or just
try it. :)

    http://module-build.sourceforge.net/META-spec-new.html

Cheers,
-Jan

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

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

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

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

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

'private' works fine.

Best regards,
Vadim.