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

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

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

> I implemented the changes to Tcl so that Tcl::icall now uses
> Tcl's unknown (AUTOLOAD) mechanism properly and kept the old
> version as Tcl::invoke (not directly used anywhere).

And you documented this properly... Very nice.

Do I understand this correctly that Tcl::invoke should be used in simple
cases to improve speed?

>
> I changed Tcl::Tk to not require the extra command stuff for
> need_tk in all cases and things still work.
>
> Seeing how small need_tk has become, I think it might be better
> to move this to the Tcl module as Tcl::pkg_require, and
> possibly take the optional args that Tcl's package require
> command allows (version and 'exact' boolean).

Cool.

Indeed, not only "Tk" stuff could be used with that, but much more.

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

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

Gisle Aas wrote:
> "Jeff Hobbs" <je...@Ac...> writes:
>>Seeing how small need_tk has become, I think it might be better
>>to move this to the Tcl module as Tcl::pkg_require, and
>>possibly take the optional args that Tcl's package require
>>command allows (version and 'exact' boolean).
> 
> Why this wrapper at all?  Why not call out to Tcl each time?
> 
> I guess I'm asking "What would be the difference between these?".
>    
>    $tcl->call("package", "require", $pkg);
>    $tcl->pkg_require($pkg);

No difference actually .... need_tk was always there, and used to
handle some special cases.  You would say need_tk("Tree") and it
would do the right thing.  However, that all seems mostly
irrelevant given the current structure, which is relatively
transparent as well as modular.  Mostly it becomes less relevant
now that icall doesn't intentionally bypass Tcl's unknown
(AUTOLOAD) mechanism, which meant special handling for the
"require" of many widgets.

The one thing it does is make sure you only do the package require
call once, which of course Tcl handles as well, so you are just
shaving off a bit of time there (on some widgets, that call is made
each time you instantiate a widget, on others, just once for the
first instantiation).

Jeff

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

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

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

> Seeing how small need_tk has become, I think it might be better
> to move this to the Tcl module as Tcl::pkg_require, and
> possibly take the optional args that Tcl's package require
> command allows (version and 'exact' boolean).

Why this wrapper at all?  Why not call out to Tcl each time?

I guess I'm asking "What would be the difference between these?".
   
   $tcl->call("package", "require", $pkg);
   $tcl->pkg_require($pkg);

--Gisle

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

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

I implemented the changes to Tcl so that Tcl::icall now uses
Tcl's unknown (AUTOLOAD) mechanism properly and kept the old
version as Tcl::invoke (not directly used anywhere).

I changed Tcl::Tk to not require the extra command stuff for
need_tk in all cases and things still work.

Seeing how small need_tk has become, I think it might be better
to move this to the Tcl module as Tcl::pkg_require, and
possibly take the optional args that Tcl's package require
command allows (version and 'exact' boolean).

Jeff

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?

Vadim.

[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] 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

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:
> 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

[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] radical rethink of Tk's loading ... (no C)

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

> I would even suggest that we bundle Tcl/Tk in the distribution itself.
> Then we have a known version we interface against and there are no
> prereqs to install the module from CPAN.  I think this is needed to
> compete with 'Tk' which already does this.

good-bye thin glue module, hello huge distribution, build FAILs, and so
on...

I think in case there will be huge distro with Tcl/Tk included (what about
Tix?), then really must be also thin distribution as alternate approach.
So people will choose between two ways.

May be already the time is come to agree on distribution names?

"Tcl"
"Tcl-all-included"

To add few words about competing with perlTk, I think first of all we need
to create standalone independent demo executables, like TkZinc has.
Another kind of demos and screenshots also necessary to do.

Additionally, I have an experience when widgets with Tcl::Tk are
considerably faster loaded and redrawn.

Best regards,
Vadim.

Re: [tcltk-perl] radical rethink of Tk's loading ... (no C)

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

I'm all for this change and for merging it all under the 'Tcl' name.

I would even suggest that we bundle Tcl/Tk in the distribution itself.
Then we have a known version we interface against and there are no
prereqs to install the module from CPAN.  I think this is needed to
compete with 'Tk' which already does this.

We should then adopt a version number derived from the version of
Tcl/Tk we bundle.

--Gisle

RE: [tcltk-perl] radical rethink of Tk's loading ... (no C)

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

> > What name of final distribution will be? I suggest moving to Tcl-Tk.
> 
> I was thinking of leaving it as "Tcl" (the distro), and it
> includes modules for 'use Tcl' and 'use Tcl::Tk'.  The use of
> Tcl::Tk can and is still independent of those that still want
> to just use Tcl.

I fully agree


> > You mean, once we'll remove Tk.xs it will be not possible 
> to add C code
> > afterwards?
> > But in this case code could be just added to Tcl.xs
> > 
> > Or I did not understood another possible problems with this?
> 
> If we remove Tk.xs, it means we will not be compiling anything
> that requires any direct build connection to Tk.  We rely on
> Tcl to handle that, treating Tk just like any other module we
> would load (as Tk really is now in the Tcl world).  If you
> wanted to add Tk_* C API invocations, that would argue for
> maintaining the separate Tcl-Tk dist.

Indeed, I forgot Tk_* API functions... And probably do not realize another
moments.
Need to think about this.

As a first thought, those Tk_* not directly needed.
As a second thought, Jeff, we must ask you for advice :)

My guess is when those will be needed we may create Tk.xs again, but this is
unlikely to happen...

> Correct, so perhaps I'll just remove the Tcl::Tk C stuff and we
> can reconsider joining the modules at a later date, after we
> have adjusted to Tcl::Tk being pure Perl, and not missing any
> access to Tk_* C APIs.

As long as we still did not used those, I can't imagine how we'll miss them
now. But I am not sure.

> 
> > I vote for moving forward.
> 
> OK, if there are no other objections, I'll do this tomorrow and
> set both Tcl and Tcl-Tk to 0.80 (prep'd for a weekend release).

Fine!
Thanks!

Best regards,
Vadim.

Re: [tcltk-perl] radical rethink of Tk's loading ... (no C)

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

Vadim Konovalov wrote:
>>This reduced Tcl::Tk to only .pm files.  That means we can
>>consider collapsing it all into the 'Tcl' distribution.  Is
>>this something we should consider?
> 
> I think this is really good.
> 
> For me, it was not very clear from very beginning why those must be two
> modules. I supposed 'Tcl' module without Tcl::Tk needed for those who needs
> Tcl without Tk, but I thought it is quite rare when a person must use Tcl
> but can't use Tk.
> 
> What name of final distribution will be? I suggest moving to Tcl-Tk.

I was thinking of leaving it as "Tcl" (the distro), and it
includes modules for 'use Tcl' and 'use Tcl::Tk'.  The use of
Tcl::Tk can and is still independent of those that still want
to just use Tcl.

Also, we might want to consider a bigger number jump if we do
this (perhaps to 1.0?).  At the same time, we can remove some
of the older bits of cruft exposed in the C API.  Every time I
look at some of those exposed bits, it reminds me of Tcl circa
1994.  We should move beyond that and make the integration
between the two really seamless.

>>Disadvantages - are we going to reach a painful growth level?
>>Will Tcl::Tk have numerous submodules eventually that we want
>>to split out?  Will there be C components for other Tk-related
>>modules that we don't yet support, but would like to?
> 
> 
> You mean, once we'll remove Tk.xs it will be not possible to add C code
> afterwards?
> But in this case code could be just added to Tcl.xs
> 
> Or I did not understood another possible problems with this?

If we remove Tk.xs, it means we will not be compiling anything
that requires any direct build connection to Tk.  We rely on
Tcl to handle that, treating Tk just like any other module we
would load (as Tk really is now in the Tcl world).  If you
wanted to add Tk_* C API invocations, that would argue for
maintaining the separate Tcl-Tk dist.

> However removing any C code from Tcl::Tk does not necessarily mean we must
> join both modules. We might do joining a little bit later.

Correct, so perhaps I'll just remove the Tcl::Tk C stuff and we
can reconsider joining the modules at a later date, after we
have adjusted to Tcl::Tk being pure Perl, and not missing any
access to Tk_* C APIs.

> I vote for moving forward.

OK, if there are no other objections, I'll do this tomorrow and
set both Tcl and Tcl-Tk to 0.80 (prep'd for a weekend release).

Jeff

Re: [tcltk-perl] radical rethink of Tk's loading ... (no C)

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

> This reduced Tcl::Tk to only .pm files.  That means we can
> consider collapsing it all into the 'Tcl' distribution.  Is
> this something we should consider?

I think this is really good.

For me, it was not very clear from very beginning why those must be two
modules. I supposed 'Tcl' module without Tcl::Tk needed for those who needs
Tcl without Tk, but I thought it is quite rare when a person must use Tcl
but can't use Tk.

What name of final distribution will be? I suggest moving to Tcl-Tk.



>
> Advantages - single distro makes it easier to maintain.
>
> Disadvantages - are we going to reach a painful growth level?
> Will Tcl::Tk have numerous submodules eventually that we want
> to split out?  Will there be C components for other Tk-related
> modules that we don't yet support, but would like to?

You mean, once we'll remove Tk.xs it will be not possible to add C code
afterwards?
But in this case code could be just added to Tcl.xs

Or I did not understood another possible problems with this?


> > Here is an idea I have about changing around Tcl::Tk, and
> > it's fairly fundamental:
> >
> > Change Tcl::Tk::new as follows:
> >
> >      $i->SUPER::Init();
> > -    $i->Init();
> > +    #$i->Init();
> > +    $i->Eval("package require Tk 8.4");
> > +    $i->call('trace', 'add', 'command', '.', 'delete',
> > +            sub { $W{'.'} = undef; });
> > +    $i->ResetResult();
> >      $Tcl::Tk::TK_VERSION = $i->GetVar("tk_version");
> >
> > and then add the following command:
> >
> > sub MainLoop {
> >     my $int = (ref $_[0]?shift:$tkinterp);
> >     while (defined $W{'.'}) {
> >        $int->DoOneEvent(0);
> >     }
> > }
> >
> > The one thing this requires is the addition of Tcl_DoOneEvent
> > to Tcl.xs (which I did for testing this).  Everything seems
> > to work just fine after these changes.  I had to make a few
> > more to force the Tk module on Linux not to load the dll
> > (which isn't necessary in any case, but I haven't fully
> > excised it from the build), but the crux of the changes work.
> >
> > This means that the only C component is on the Tcl side -
> > there is NO Tk C component, only Tk.pm.  The loading an
> > initialization of Tk is build into the 'package require Tk' statement.

I think this will only be good.
Tk.xs is extremely small and no-one will notice if it will be removed :)

However removing any C code from Tcl::Tk does not necessarily mean we must
join both modules. We might do joining a little bit later.

> >
> > The disadvantage here is removing any access at the C level
> > to Tk stuff, but currently there is nothing there we use.
> >
> > At the same time, I have a patch which adds Tcl stubs support
> > to the Tcl module.  That means we gain Tcl version
> > independence and have more control over what Tcl is used at
> > runtime.  More on that here:
> > http://aspn.activestate.com/ASPN/docs/ActiveTcl/tcl/TclLib/InitStubs.htm

I vote for moving forward.

Best regards,
Vadim.

RE: [tcltk-perl] radical rethink of Tk's loading ... (no C)

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

In addition to this, there is a large extra question ...

This reduced Tcl::Tk to only .pm files.  That means we can
consider collapsing it all into the 'Tcl' distribution.  Is
this something we should consider?

Advantages - single distro makes it easier to maintain.

Disadvantages - are we going to reach a painful growth level?
Will Tcl::Tk have numerous submodules eventually that we want
to split out?  Will there be C components for other Tk-related
modules that we don't yet support, but would like to?

Jeff

> -----Original Message-----
> From: tcl...@li... 
> [mailto:tcl...@li...] On Behalf Of 
> Jeff Hobbs
> Sent: Wednesday, April 28, 2004 4:28 PM
> To: tcl...@li...
> Subject: [tcltk-perl] radical rethink of Tk's loading ... (no C)
> 
> 
> Here is an idea I have about changing around Tcl::Tk, and 
> it's fairly fundamental:
> 
> Change Tcl::Tk::new as follows:
> 
>      $i->SUPER::Init();
> -    $i->Init();
> +    #$i->Init();
> +    $i->Eval("package require Tk 8.4");
> +    $i->call('trace', 'add', 'command', '.', 'delete',
> +            sub { $W{'.'} = undef; });
> +    $i->ResetResult();
>      $Tcl::Tk::TK_VERSION = $i->GetVar("tk_version");
> 
> and then add the following command:
> 
> sub MainLoop {
>     my $int = (ref $_[0]?shift:$tkinterp);
>     while (defined $W{'.'}) {
>        $int->DoOneEvent(0);
>     }
> }
> 
> The one thing this requires is the addition of Tcl_DoOneEvent 
> to Tcl.xs (which I did for testing this).  Everything seems 
> to work just fine after these changes.  I had to make a few 
> more to force the Tk module on Linux not to load the dll 
> (which isn't necessary in any case, but I haven't fully 
> excised it from the build), but the crux of the changes work.
> 
> This means that the only C component is on the Tcl side - 
> there is NO Tk C component, only Tk.pm.  The loading an 
> initialization of Tk is build into the 'package require Tk' statement.
> 
> The disadvantage here is removing any access at the C level 
> to Tk stuff, but currently there is nothing there we use.
> 
> At the same time, I have a patch which adds Tcl stubs support 
> to the Tcl module.  That means we gain Tcl version 
> independence and have more control over what Tcl is used at 
> runtime.  More on that here:
> http://aspn.activestate.com/ASPN/docs/ActiveTcl/tcl/TclLib/InitStubs.htm

[tcltk-perl] radical rethink of Tk's loading ... (no C)

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

Here is an idea I have about changing around Tcl::Tk, and it's
fairly fundamental:

Change Tcl::Tk::new as follows:

     $i->SUPER::Init();
-    $i->Init();
+    #$i->Init();
+    $i->Eval("package require Tk 8.4");
+    $i->call('trace', 'add', 'command', '.', 'delete',
+            sub { $W{'.'} = undef; });
+    $i->ResetResult();
     $Tcl::Tk::TK_VERSION = $i->GetVar("tk_version");

and then add the following command:

sub MainLoop {
    my $int = (ref $_[0]?shift:$tkinterp);
    while (defined $W{'.'}) {
       $int->DoOneEvent(0);
    }
}

The one thing this requires is the addition of Tcl_DoOneEvent to
Tcl.xs (which I did for testing this).  Everything seems to work
just fine after these changes.  I had to make a few more to force
the Tk module on Linux not to load the dll (which isn't necessary
in any case, but I haven't fully excised it from the build), but
the crux of the changes work.

This means that the only C component is on the Tcl side - there
is NO Tk C component, only Tk.pm.  The loading an initialization
of Tk is build into the 'package require Tk' statement.

The disadvantage here is removing any access at the C level to
Tk stuff, but currently there is nothing there we use.

At the same time, I have a patch which adds Tcl stubs support to
the Tcl module.  That means we gain Tcl version independence and
have more control over what Tcl is used at runtime.  More on
that here:

http://aspn.activestate.com/ASPN/docs/ActiveTcl/tcl/TclLib/InitStubs.htm

Jeff

Re: [tcltk-perl] return of 1=>1.0 transformation error

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

> > Or just add more checks to the code so that it creates int 
> > objects whenever that would be an exact translation of the 
> > SV.  A few more conditionals and it should be all ok again.
> 
> Vadim - please verify that just removing the "SvIOK(sv) &&"
> condition is all that is necessary.  IOW:

This cures the problem, no more fails in perl-5.6.1.

Thank you for providing a fix!


> 
>     else if (SvNOK(sv)) {
> double dval = SvNV(sv);
> int ival;
> /*
> * Perl does math with doubles by default, so 0 + 1 == 1.0.
> * Check for int-equiv doubles and make those ints.
> */
> if ((double)(ival = SvIV(sv)) == dval) {
>     objPtr = Tcl_NewIntObj(ival);
> } else {
>     objPtr = Tcl_NewDoubleObj(dval);
> }
>     }
> 
> we could possibly save a cycle or two with:
> 
> if ((double)(ival = (int)dval) == dval) {
> 
> but I'm not sure avoiding the SvIV is a good idea.  ???

I may be wrong, but probably your fix could be #ifdef-ed for perl-5.6.1? 
But in this case there will be unnecessary complications, IMHO

Vadim.

RE: [tcltk-perl] return of 1=>1.0 transformation error

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

> > Much better to early stringification early.
> 
> Or just add more checks to the code so that it creates int 
> objects whenever that would be an exact translation of the 
> SV.  A few more conditionals and it should be all ok again.

Vadim - please verify that just removing the "SvIOK(sv) &&"
condition is all that is necessary.  IOW:

    else if (SvNOK(sv)) {
	double dval = SvNV(sv);
	int ival;
	/*
	 * Perl does math with doubles by default, so 0 + 1 == 1.0.
	 * Check for int-equiv doubles and make those ints.
	 */
	if ((double)(ival = SvIV(sv)) == dval) {
	    objPtr = Tcl_NewIntObj(ival);
	} else {
	    objPtr = Tcl_NewDoubleObj(dval);
	}
    }

we could possibly save a cycle or two with:

	if ((double)(ival = (int)dval) == dval) {

but I'm not sure avoiding the SvIV is a good idea.  ???

Jeff

Re: [tcltk-perl] return of 1=>1.0 transformation error

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

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

> > There are no integer literals in Perl.  All numbers and arithmetics
> > are/are done with doubles.  If you want to force integers you need to
> > declare that intention with the 'use integer' pragma.  perl might try
> > to use integers when it can get away with it and newer version are
> > more aggressively doing so, but there are no guarantees.
> 
> 'use integer;' will probably bring problems with having this pragma turned
> on/off when user do not expect it to be changed somehow.

The user code would have to use this pragma.  It is lexical and it is
the user's numbers we want to be ints.  Because of this it is not a
solution to this problem.  I just mentioned it to describe how perl works.

> Much better to early stringification early.

Or just add more checks to the code so that it creates int objects
whenever that would be an exact translation of the SV.  A few more
conditionals and it should be all ok again.

--Gisle

RE: [tcltk-perl] return of 1=>1.0 transformation error

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

> 	if (SvIOK(sv) && ((double)(ival = SvIV(sv)) == dval)) {
> 
> returns different results for 0 as 1.0, but a quick C check
> with this:
> 
>     int ival = 1;
>     double dval = 1.0;
>     printf("%d\n", (((double)(ival = (int)dval)) == dval));
> 
> Says it should convert back and forth OK (that shows '1').  I
> know you will have issues with incorrect double equality on
> some corner cases.
> 
> > You can investigate this using Devel::Peek.  It is not part 
> 
> I only have 5.8 installed, so it always works for me.  Perhaps
> Vadim would like to hunt this down?

I will hunt this down with a great pleasure, but will not have possibility
to do this until nearest Saturday.
For sure will do, but probably someone will do this faster.

Vadim.

RE: [tcltk-perl] return of 1=>1.0 transformation error

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

> There are no integer literals in Perl.  All numbers and arithmetics
> are/are done with doubles.  If you want to force integers you need to
> declare that intention with the 'use integer' pragma.  perl might try
> to use integers when it can get away with it and newer version are
> more aggressively doing so, but there are no guarantees.

'use integer;' will probably bring problems with having this pragma turned
on/off when user do not expect it to be changed somehow.
Much better to early stringification early.

Vadim.

RE: [tcltk-perl] return of 1=>1.0 transformation error

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

> > my $row = 0;
> > foreach my $leaf('Tk.xbm','Xcamel.gif')
> >  {
	...
> >   my $col = 0;
> >   $mw->Label(-text  => 'Initial')
> > 	->grid(-row => $row, -column => $col);
> >   $mw->Label(-background => 'white',-image => $src)
> > 	->grid(-row => $row+1, -column => $col++);
> > 	...
> > 
> > We see that the problem is at -row 1, so that last line is the issue.  
> > That this becomes SvNOK w/o being SvIOK in Perl 5.6 seems "just wrong" 

> Perl 5.6.1 doesn't do anything weird there for me.  Maybe it it the
> grid() method that modifies the SV?

grid only ever passes the args through, and this is only ever
touched by the C internals.  That means it goes through the
same path when == 0 as == 1.  It's possible that this code:

	if (SvIOK(sv) && ((double)(ival = SvIV(sv)) == dval)) {

returns different results for 0 as 1.0, but a quick C check
with this:

    int ival = 1;
    double dval = 1.0;
    printf("%d\n", (((double)(ival = (int)dval)) == dval));

Says it should convert back and forth OK (that shows '1').  I
know you will have issues with incorrect double equality on
some corner cases.

> You can investigate this using Devel::Peek.  It is not part 

I only have 5.8 installed, so it always works for me.  Perhaps
Vadim would like to hunt this down?

Jeff

Re: [tcltk-perl] return of 1=>1.0 transformation error

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

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

> We see that the problem is at -row 1, so that last line is the
> issue.  That this becomes SvNOK w/o being SvIOK in Perl 5.6
> seems "just wrong" to me (and obviously to others as 5.8 corrects
> the issue).  You guys are right that I should try without the
> SvIOK as well, but still, this is a wacky promotion behavior.

There are no integer literals in Perl.  All numbers and arithmetics
are/are done with doubles.  If you want to force integers you need to
declare that intention with the 'use integer' pragma.  perl might try
to use integers when it can get away with it and newer version are
more aggressively doing so, but there are no guarantees.

--Gisle