On Tue, Aug 04, 2009 at 01:29:51PM -0700, Dan Price wrote: > On Tue 04 Aug 2009 at 02:41PM, Shawn Walker wrote: > > [email protected] wrote: > > >Folks, > > >Ed seems to be hitting all of our libcurl bugs. He's been getting some > > >kind of progress tracking mismatch that we've been trying to track down. > > >With the latest code, he gets a type mismatch trying to print out the > > >values. This implies that somehow one or more of these values isn't an > > >integer. I've gone back and adjusted to code to convert the values to > > >strings. This change also makes sure that all of the values passed to > > >download_add_progress are integers. > > > > > > http://cr.opensolaris.org/~johansen/webrev-10449/ > > I'm very confused here. > > progress.py: > > 185 + emsg("\nExpected %s pkgs, received %s pkgs > instead." % > 186 (self.dl_goal_npkgs, > self.dl_cur_npkgs)) > > I'm lost. How could these not be ints? We specifically set > dl_cur_npkgs = 0 in the constructor.
The problem occurs in Engine.cleanup_requests(). It calls h.getinfo(pycurl.SIZE_DOWNLOAD), which returns a double. That value is then passed to FileProgress.commit() as the size argument. (h.fileprog.commit()). I believe that I was pretty careful about converting to integers, but it looks like I missed that particular case. > Wouldn't it make more sense to assert the type of the input parameters > into the progress tracking? That's also a reasonable solution. Personally, I miss having the type checker that's in C, since I'd find these problems at compile time, instead of hoping that it hit this assert at some point and am around to fix the code. > transport.py: > 836 + self._progtrack.download_add_progress(-1 > ,int(-size)) > > If 'size' is not an int to begin with, how can it be negated > before a cast to int? Like this: >>> v = 1.25 >>> print int(-v) -1 >>> -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
