From: David M. <da...@re...> - 2003-04-29 03:02:25
|
Hi all Firstly, thanks to the authors for Python Mega Widgets, and especially for the fact that PMW has no dependencies outside of TkInter. Well done! There's only one slight problem. Due to the dynamic import mechanisms, it is not possible to build truly standalone binaries via tools like Py2EXE or McMillan Installer. In a desperate move, I've consolidated all of PMW into a single file, and ripped out all dynamic imports. The result is a module which can be incorporated into a standalone app, and won't create any dramas at run time. The results are excellent - there seems to be no undue overhead with first import of the module. I'm personally of the opinion that dynamic importing creates more problems than it solves. Thoughts, people? -- Kind regards David -- leave this line intact so your email gets through my junk mail filter |
From: David M. <da...@re...> - 2003-04-29 03:44:32
|
On Tue, 2003-04-29 at 14:56, David McNab wrote: > Hi all > > Firstly, thanks to the authors for Python Mega Widgets, and especially > for the fact that PMW has no dependencies outside of TkInter. > Well done! > > There's only one slight problem. Due to the dynamic import mechanisms, > it is not possible to build truly standalone binaries via tools like > Py2EXE or McMillan Installer. > > In a desperate move, I've consolidated all of PMW into a single file, > and ripped out all dynamic imports. Oh, if only I'd read the doco and referred to the section on 'freezing' :) Anyway, compliments on a fine package. After struggling with other GUI packages, where I've often had to do dir() and a lot of 'method hunting', it makes a hell of a change to have decent doco for a change. You guys certainly set the standard for Python module development! Cheers David > The result is a module which can be > incorporated into a standalone app, and won't create any dramas at run > time. The results are excellent - there seems to be no undue overhead > with first import of the module. > > I'm personally of the opinion that dynamic importing creates more > problems than it solves. > > Thoughts, people? -- Kind regards David -- leave this line intact so your email gets through my junk mail filter |
From: Greg M. <gr...@in...> - 2003-04-30 13:38:09
|
David, Thanks for the kind words. It is encouragement like this that keeps free software going! There were two main reasons for dynamic importing. One was to allow multiple (possibly incompatible) versions of Pmw to co-exist so that applications built using an older version of Pmw did not have be recoded when a new version of Pmw was released. This allowed other applications to be built against newer versions of Pmw. I am not sure whether this feature is used much, but at the original home of Pmw (at Telstra in Australia) we had a fairly fast development schedule with different projects being developed at different times, so it was important that any new releases of Pmw did not break existing applications currently being used in production. The other reason was speed of startup. Pmw is fairly old and machines were not as fast as today, so it did make a significant difference not to import all of Pmw at startup. It allowed the users to see the main window of applications fast. Also, it allows Pmw to grow to contain many more megawidgets than it currently does without affecting load times at all. Anyway, I hope you find Pmw useful. Greg On Tue 29 Apr 2003 at 03:38:35PM +1200, David McNab wrote: > On Tue, 2003-04-29 at 14:56, David McNab wrote: > > Hi all > > > > Firstly, thanks to the authors for Python Mega Widgets, and especially > > for the fact that PMW has no dependencies outside of TkInter. > > Well done! > > > > There's only one slight problem. Due to the dynamic import mechanisms, > > it is not possible to build truly standalone binaries via tools like > > Py2EXE or McMillan Installer. > > > > In a desperate move, I've consolidated all of PMW into a single file, > > and ripped out all dynamic imports. > > Oh, if only I'd read the doco and referred to the section on 'freezing' > :) > > Anyway, compliments on a fine package. > > After struggling with other GUI packages, where I've often had to do > dir() and a lot of 'method hunting', it makes a hell of a change to have > decent doco for a change. > > You guys certainly set the standard for Python module development! > > Cheers > David > > > The result is a module which can be > > incorporated into a standalone app, and won't create any dramas at run > > time. The results are excellent - there seems to be no undue overhead > > with first import of the module. > > > > I'm personally of the opinion that dynamic importing creates more > > problems than it solves. > > > > Thoughts, people? > -- > Kind regards > David > > -- > > leave this line intact so your email gets through my junk mail filter > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Pmw-general mailing list > Pmw...@li... > https://lists.sourceforge.net/lists/listinfo/pmw-general -- Greg McFarlane Really Good Software Pty Ltd Sydney Australia gr...@in... |
From: Ike H. <ha...@nh...> - 2003-04-30 14:18:29
|
Hi all, A few weeks ago I posted asking if anyone else saw the memory leak I saw in Pmw.Blt.Graph(). After doing a bit more playing with sample code, and some method hunting, I found that the memory leak actually exists in Pmw.Blt.Vector and is a known bug in BLT. (apparently patches are comming) But, there is a way aound this. Generally, according to sample code on the Pmw website, Vectors are to be treated *almost* the same as lists (at least that is my impression) so that if you have a line with a vector (or 2 vectors) defining the points on the line, one can just modify the values, or append values on the end or remove them or whatever, the same as on would for a python list. However, doing any of these is the cause of the memory leak. There is an alternative, which is a bit more CPU intensive, but if one is graphing lots of data (as I was when I discovered this) the memory problem goes away. the trick is to list-ify the vector by using the command list(vector) and making modifications to the data in the list object you create, then using Pmw.Blt.Vector.set(list) to 'set' the vector to the data in the list. Example: Old way: vector=Pmw.Blt.Vector() #creation for i in range(10): vector.append(i) #just putting incremental numbers in the vector...doing this alot causes mem probs #updating for i in range(len(vector)): vector[i]=i+1 #this method of updating also causes problems New way: vector=Pmw.Blt.Vector() #creation a=[] for i in range(10): a.append(i) vector.set(a) #updating a=list(vector) for i in range(len(a)): a[i]=a+1 vector.set(a) and voilia, memory leak problem goes away. |
From: Greg M. <gr...@in...> - 2003-05-02 12:19:26
|
Ike, You do not even need to use Pmw.Blt.Vector at all. I generally use normal python lists to create the data arrays and convert them to tuples using tuple() when passing to bar_create() or line_create() methods of Pmw.Blt.Graph. # ------------------------------------------------------------------- import Pmw graph = Pmw.Blt.Graph() graph.pack() xdata = [] ydata = [] for i in range(100): xdata.append(i - 50) ydata.append((i - 50) * (i - 50)) graph.line_create('smile', xdata = tuple(xdata), ydata = tuple(ydata)) graph.line_create('lefteye', xdata = (-30,), ydata = (4000,)) graph.line_create('righteye', xdata = (30,), ydata = (4000,)) # ------------------------------------------------------------------- Greg On Wed 30 Apr 2003 at 09:18:50AM -0500, Ike Hall wrote: > Hi all, > > A few weeks ago I posted asking if anyone else saw the memory leak I saw in > Pmw.Blt.Graph(). After doing a bit more playing with sample code, and some > method hunting, I found that the memory leak actually exists in > Pmw.Blt.Vector and is a known bug in BLT. (apparently patches are comming) > But, there is a way aound this. > > Generally, according to sample code on the Pmw website, Vectors are to be > treated *almost* the same as lists (at least that is my impression) so that > if you have a line with a vector (or 2 vectors) defining the points on the > line, one can just modify the values, or append values on the end or remove > them or whatever, the same as on would for a python list. However, doing > any of these is the cause of the memory leak. There is an alternative, > which is a bit more CPU intensive, but if one is graphing lots of data (as I > was when I discovered this) the memory problem goes away. the trick is to > list-ify the vector by using the command list(vector) and making > modifications to the data in the list object you create, then using > Pmw.Blt.Vector.set(list) to 'set' the vector to the data in the list. > > Example: > > Old way: > > vector=Pmw.Blt.Vector() > #creation > for i in range(10): > vector.append(i) #just putting incremental numbers in the > vector...doing this alot causes mem probs > > #updating > for i in range(len(vector)): > vector[i]=i+1 #this method of updating also causes problems > > > New way: > > vector=Pmw.Blt.Vector() > #creation > a=[] > for i in range(10): > a.append(i) > vector.set(a) > > #updating > a=list(vector) > for i in range(len(a)): > a[i]=a+1 > vector.set(a) > > and voilia, memory leak problem goes away. > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Pmw-general mailing list > Pmw...@li... > https://lists.sourceforge.net/lists/listinfo/pmw-general -- Greg McFarlane Really Good Software Pty Ltd Sydney Australia gr...@in... |
From: Isaac H. <ha...@ou...> - 2003-05-02 13:53:02
|
Hi Greg, Actually, it turns out that using tuples for stripcharting (which is what I am doing) is more cumbersome than just using the vectors. The vectors have the nice feature that making a change to the vectors makes a change in the graph, so for stripcharts that update every 5 seconds, it has been easier for me to just use a vector than to make tuples and create and delete lines every time. Ike On Fri, 2 May 2003, Greg McFarlane wrote: > Ike, > > You do not even need to use Pmw.Blt.Vector at all. I generally use > normal python lists to create the data arrays and convert them to > tuples using tuple() when passing to bar_create() or line_create() > methods of Pmw.Blt.Graph. > > # ------------------------------------------------------------------- > import Pmw > graph = Pmw.Blt.Graph() > graph.pack() > xdata = [] > ydata = [] > for i in range(100): > xdata.append(i - 50) > ydata.append((i - 50) * (i - 50)) > graph.line_create('smile', xdata = tuple(xdata), ydata = tuple(ydata)) > graph.line_create('lefteye', xdata = (-30,), ydata = (4000,)) > graph.line_create('righteye', xdata = (30,), ydata = (4000,)) > # ------------------------------------------------------------------- > > Greg > > On Wed 30 Apr 2003 at 09:18:50AM -0500, Ike Hall wrote: > > Hi all, > > > > A few weeks ago I posted asking if anyone else saw the memory leak I saw in > > Pmw.Blt.Graph(). After doing a bit more playing with sample code, and some > > method hunting, I found that the memory leak actually exists in > > Pmw.Blt.Vector and is a known bug in BLT. (apparently patches are comming) > > But, there is a way aound this. > > > > Generally, according to sample code on the Pmw website, Vectors are to be > > treated *almost* the same as lists (at least that is my impression) so that > > if you have a line with a vector (or 2 vectors) defining the points on the > > line, one can just modify the values, or append values on the end or remove > > them or whatever, the same as on would for a python list. However, doing > > any of these is the cause of the memory leak. There is an alternative, > > which is a bit more CPU intensive, but if one is graphing lots of data (as I > > was when I discovered this) the memory problem goes away. the trick is to > > list-ify the vector by using the command list(vector) and making > > modifications to the data in the list object you create, then using > > Pmw.Blt.Vector.set(list) to 'set' the vector to the data in the list. > > > > Example: > > > > Old way: > > > > vector=Pmw.Blt.Vector() > > #creation > > for i in range(10): > > vector.append(i) #just putting incremental numbers in the > > vector...doing this alot causes mem probs > > > > #updating > > for i in range(len(vector)): > > vector[i]=i+1 #this method of updating also causes problems > > > > > > New way: > > > > vector=Pmw.Blt.Vector() > > #creation > > a=[] > > for i in range(10): > > a.append(i) > > vector.set(a) > > > > #updating > > a=list(vector) > > for i in range(len(a)): > > a[i]=a+1 > > vector.set(a) > > > > and voilia, memory leak problem goes away. > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Pmw-general mailing list > > Pmw...@li... > > https://lists.sourceforge.net/lists/listinfo/pmw-general > > -- |