Thread: [tcltk-perl] return of 1=>1.0 transformation error
Brought to you by:
hobbs
Menu
▾
▴
tcltk-perl
|
From: Konovalov, V. <vko...@sp...> - 2004-04-28 05:51:02
|
Dear all,
I did not checked for details yet, but when I tried CVS version of Tcl and
Tcl::Tk I gave failed test for t/photo.t
Output is below:
Tcl error 'bad grid value "1.0": must be a non-negative integer at
d:/Perl56/site/lib/Tcl.pm line 363.
' while invoking scalar result call:
"grid .lbl02 -row 1 -column 0" at d:/Perl56/site/lib/Tcl.pm line 364
Tcl::call('Tcl::Tk=SCALAR(0x1b8f0d8)', 'grid', '.lbl02', '-row', 1,
'-column', 0) called at d:/Perl56/site/lib/Tcl/Tk.pm line 750
Tcl::Tk::Widget::grid('Tcl::Tk::Widget::Label=SCALAR(0x20cdb14)',
'-row', 1, '-column', 0) called at t/photo.t line 23
Interesting to say, tests for geometry manager do not catch this, but
t/photo.t does
perl-5.8.2 passes test without this error, 5.6.0 and 5.6.1 fail.
If anyone have ideas how to fix, please share your knowledge.
Best regards,
Vadim.
|
|
From: Jeff H. <je...@ac...> - 2004-04-28 16:31:06
|
> Tcl error 'bad grid value "1.0": must be a non-negative
> integer at d:/Perl56/site/lib/Tcl.pm line 363. ' while
> invoking scalar result call:
> "grid .lbl02 -row 1 -column 0" at
...
> perl-5.8.2 passes test without this error, 5.6.0 and 5.6.1 fail.
This is specifically supposed to be handled by this code in
TclObjFromSv:
else if (SvNOK(sv)) {
double dval = SvNV(sv);
int ival;
/*
* Account for some perl versions aggressive NOK-ness where
* an int was all that was intented.
*/
if (SvIOK(sv) && ((double)(ival = SvIV(sv)) == dval)) {
objPtr = Tcl_NewIntObj(ival);
} else {
objPtr = Tcl_NewDoubleObj(dval);
}
}
as it was an issue that 5.6 decided to aggressively promote
"1" with SvNOK as well as SvIOK, whereas 5.8 is corrected to
not do that.
Jeff
|
|
From: Gisle A. <gi...@Ac...> - 2004-04-28 16:42:03
|
"Jeff Hobbs" <je...@Ac...> writes:
> > Tcl error 'bad grid value "1.0": must be a non-negative
> > integer at d:/Perl56/site/lib/Tcl.pm line 363. ' while
> > invoking scalar result call:
> > "grid .lbl02 -row 1 -column 0" at
> ...
> > perl-5.8.2 passes test without this error, 5.6.0 and 5.6.1 fail.
>
> This is specifically supposed to be handled by this code in
> TclObjFromSv:
>
> else if (SvNOK(sv)) {
> double dval = SvNV(sv);
> int ival;
> /*
> * Account for some perl versions aggressive NOK-ness where
> * an int was all that was intented.
> */
> if (SvIOK(sv) && ((double)(ival = SvIV(sv)) == dval)) {
I think you should remove the SvIOK() test here. Then it should work
even for SVs where only the NOK flag is set, but still contains a
whole duble. That might happen as well.
This will have problem with very large values though. Hmm. You
probably also need to test that dval is within the integer range.
> objPtr = Tcl_NewIntObj(ival);
> } else {
> objPtr = Tcl_NewDoubleObj(dval);
> }
> }
>
> as it was an issue that 5.6 decided to aggressively promote
> "1" with SvNOK as well as SvIOK, whereas 5.8 is corrected to
> not do that.
>
> Jeff
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Tcltk-perl mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcltk-perl
|
|
From: Jan D. <ja...@Ac...> - 2004-04-28 16:53:16
|
> > Tcl error 'bad grid value "1.0": must be a non-negative
> > integer at d:/Perl56/site/lib/Tcl.pm line 363. ' while
> > invoking scalar result call:
> > "grid .lbl02 -row 1 -column 0" at
> ...
> > perl-5.8.2 passes test without this error, 5.6.0 and 5.6.1 fail.
>
> This is specifically supposed to be handled by this code in
> TclObjFromSv:
>
> else if (SvNOK(sv)) {
> double dval = SvNV(sv);
> int ival;
> /*
> * Account for some perl versions aggressive NOK-ness where
> * an int was all that was intented.
> */
> if (SvIOK(sv) && ((double)(ival = SvIV(sv)) == dval)) {
> objPtr = Tcl_NewIntObj(ival);
> } else {
> objPtr = Tcl_NewDoubleObj(dval);
> }
> }
>
> as it was an issue that 5.6 decided to aggressively promote
> "1" with SvNOK as well as SvIOK, whereas 5.8 is corrected to
> not do that.
That code will not catch the case when the floating point value has
already been stringified.
What is weird thought is that Perl would still stringify an NV of value
1.0 as "1" and not "1.0". So is it possible that the value already got
round-tripped through Tcl?
Cheers,
-Jan
|
|
From: Jeff H. <je...@Ac...> - 2004-04-28 17:01:15
|
This is the exact code being run:
my $row = 0;
foreach my $leaf('Tk.xbm','Xcamel.gif')
{
my $file = "./t/$leaf"; #Tk->findINC($leaf);
my $src = $mw->Photo(-file => $file);
ok(defined($src),1," Cannot load $file");
my $kind = 'Initial';
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" 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.
Jeff
> > > Tcl error 'bad grid value "1.0": must be a non-negative integer at
> > > d:/Perl56/site/lib/Tcl.pm line 363. ' while invoking scalar result
> > > call:
> > > "grid .lbl02 -row 1 -column 0" at
> > ...
> > > perl-5.8.2 passes test without this error, 5.6.0 and 5.6.1 fail.
> >
> > This is specifically supposed to be handled by this code in
> > TclObjFromSv:
> >
> > else if (SvNOK(sv)) {
> > double dval = SvNV(sv);
> > int ival;
> > /*
> > * Account for some perl versions aggressive NOK-ness where
> > * an int was all that was intented.
> > */
> > if (SvIOK(sv) && ((double)(ival = SvIV(sv)) == dval)) {
> > objPtr = Tcl_NewIntObj(ival);
> > } else {
> > objPtr = Tcl_NewDoubleObj(dval);
> > }
> > }
> >
> > as it was an issue that 5.6 decided to aggressively promote "1" with
> > SvNOK as well as SvIOK, whereas 5.8 is corrected to not do that.
>
> That code will not catch the case when the floating point
> value has already been stringified.
>
> What is weird thought is that Perl would still stringify an
> NV of value 1.0 as "1" and not "1.0". So is it possible that
> the value already got round-tripped through Tcl?
|
|
From: Jan D. <ja...@Ac...> - 2004-04-28 17:05:51
|
> This is the exact code being run:
>
> my $row = 0;
> foreach my $leaf('Tk.xbm','Xcamel.gif')
> {
> my $file = "./t/$leaf"; #Tk->findINC($leaf);
> my $src = $mw->Photo(-file => $file);
> ok(defined($src),1," Cannot load $file");
> my $kind = 'Initial';
> 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" 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.
Perl 5.6.1 doesn't do anything weird there for me. Maybe it it the
grid() method that modifies the SV?
You can investigate this using Devel::Peek. It is not part of standard
Perl, but you can install it with PPM for ActivePerl. Then insert
require Devel::Peek;
Devel::Peek::Dump($row);
Before each usage of $row and see where things change.
Cheers,
-Jan
|
|
From: Jeff H. <je...@Ac...> - 2004-04-28 17:27:25
|
> > 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
|
|
From: Gisle A. <gi...@Ac...> - 2004-04-28 17:14:22
|
"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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X