Hi,
A new test build of wxPython has been uploaded to starship.
Version: 2.5.2.2p.20040628
Pythons: 2.3
URL: http://starship.python.net/crew/robind/wxPython/daily/20040628
Have fun!
R'bot
Hi,
A new test build of wxPython has been uploaded to starship.
Version: 2.5.2.2p.20040628
Pythons: 2.3
URL: http://starship.python.net/crew/robind/wxPython/daily/20040628
Have fun!
R'bot
The new build seems to be working well so far, the text ctrl problem is fixed.
I'm having a problem with the size of SpinCtrls. It seems they are always the same size (too wide) and even setting a specific size on creation doesn't change it. This was happening in the previous build too. It happens whether I use FIXED_MINSIZE or not. I also see that the SpinCtrl in the demo is the same size, and I can't modify its size in the demo code either.
R'bot wrote:
Hi,
A new test build of wxPython has been uploaded to starship.
Version: 2.5.2.2p.20040628
Pythons: 2.3
URL: http://starship.python.net/crew/robind/wxPython/daily/20040628
Austin Luminais wrote:
The new build seems to be working well so far, the text ctrl problem is fixed.
I'm having a problem with the size of SpinCtrls. It seems they are always the same size (too wide) and even setting a specific size on creation doesn't change it. This was happening in the previous build too. It happens whether I use FIXED_MINSIZE or not. I also see that the SpinCtrl in the demo is the same size, and I can't modify its size in the demo code either.
Which platform?
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
Which platform?
Windows 2000.
Austin Luminais wrote:
Robin Dunn wrote:
Which platform?
Windows 2000.
It sizes correctly outside of sizers for me, but I am seeing the problem when the spinctrl is in a sizer. Looks like the minsize is not being set when passed to the contructor. I shoudl be able to fix that today.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin et al,
There's been some discussion lately over on the NumPy list about using
the new numarray package with wxPython. It was found that using
numarrays with wx.DC.DrawLines (for instance) was much slower than using
Numeric arrays. This is mostly a numarray problem, but in the discussion
it has come up that it would obviously be much faster if numarrays
(and/or Numeric arrays) could be accessed directly by wxPython. The
Numarray folks have come up with a PEP (enclosed) about including just the headers of numarray in the standard Python distribution to make this easier, but in the meantime, I think you could have some incite into he rest of the discussion that has ensued, mostly between Todd Miller, the lead numarray developer, and Tim Hochberg, whom you know.
Below is a summary, the whole thread is here:
http://sourceforge.net/mailarchive/message.php?msg_id=8835428
Actually some of the thread, the threaded view doesn't seem to be
working well.
Here are some excerpts:
.......
The large number of "Check" routines preceding the numarray path (I
count 7 looking at my copy of wxPython) has me a little concerned. I
think those checks are more expensive for numarray because it is a new
style class. I have a hard time imagining a 10x difference overall,
but I think Python does have to traverse the numarray class hierarchy
rather than do a type pointer comparison so they are more expensive.
........
I don't see any easy/obvious ways to speed up wxPySwigInstance_Check,
Why no CheckExact, even if it's hand coded? Maybe the setup is tedious?
I don't know although I suspect the setup being tedious might be part of
it. I also believe that until recently, wxPython used old style classes
and you couldn't use CheckExact. What I propose below is essentially a
hand coded version of check exact for wxPoints.
but I believe that wxPoints now obey the PySequence protocol, so I think
that the whole wxPySwigInstance_Check branch could be removed. To get
that into wxPython you'd probably have to convince Robin that it
wouldn't hurt the speed of list of wxPoints unduly.
Wait... If the above doesn't work, I think I do have a way that might
work for speeding the check for a wxPoint. Before the loop starts, get a
pointer to wx.core.Point (the class for wxPoints these days) and call it
wxPoint_Type. Then just use for the check:
o->ob_type == &wxPoint_Type
Worth a try anyway.
....
What's the chance of adding direct support for numarray to wxPython? Our
PEP reduces the burden on a package to at worst adding 3 include
files for numarray plus the specialized package code. With those
files, the
header_pep.txt (9.62 KB)
PyQwt is a Python extension which can be conditionally compiled against
> Numeric and/or numarray (both, one of them or none).
Well that's cool! I'll have to keep the PyQwt guys in mind as potential
first users.> Your PEP excludes importing of Numeric and numarray in the same C-extension.
This is true but I don't understand your solution so I'll blather on
below.> All you need to do is to hide the macros PyArray_Present(), PyArray_isArray()
> and import_array() into a few functions with numarray specific names, so
> that the following becomes possible:
> > #include <Numeric/meta.h>
> /* defines the functions (no macros)
> int Numeric_Present();
> int Numeric_isArray();
> void import_numeric();
> to hide the Numeric C-API stuff in a small Numeric/meta.c file.
> */
> #include <numarray/meta.h>
> /* defines the functions (no macros)
> int numarray_Present();
> int numarray_isArray();
> void import_numarray();
> to hide the numarray C-API stuff in a small numarray/meta.c file.
> */
>I may have come up with the wrong scheme for the Present() and
isArray(). With my scheme, they *have* to be macros because the API
functions are unsafe: when numarray or Numeric is not present, the API
function table pointers are NULL so calling through them results in
either a fatal error or a segfault.The macros can be hidden from the module file scope by wrapping them
in a function (see attached demo)There is an additional problem that the "same functions" need to be
called through different API pointers depending on whether numarray or Numeric is being supported. Redefinition of typedefs and enumerations(or perhaps conditional compilation short-circuited re-definitions) may
also present a problem with compiling (or worse, running).Tested and works.
I certainly like the idea of supporting both in the same extension
module, but don't see how to get there, other than with separate
compilation units. With seperate .c files, I'm not aware of a problem
other than lots of global symbols. I haven't demoed that yet so I am
interested if someone has made it work.Yes, you cannot mix the numarray API and Numeric API in the same .c
file, but nevertheless you can hide the macros in small functions so
that the macros don't pollute.Here you have a litte extension module 'pep' which tries to import Numeric
and numarray. It has a method 'whatsThere' that prints the names of
the Numerical/numarray extension modules it has imported.It has also a method 'whatsThis' that prints if an object is a Numeric
array, a numarray array or something else:Python 2.3.3 (#2, Feb 17 2004, 11:45:40)
[GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2
Type "help", "copyright", "credits" or "license" for more information.import pep
pep.whatsThere()Numeric!
Numarray!import Numeric
a = Numeric.arange(10)
pep.whatsThis(a)Numeric array
import numarray
a = numarray.arange(10)
pep.whatsThis(a)Numarray array
a = 10
pep.whatsThis(a)Something else
The MANIFEST reads:
pepmodule.c
setup.py
Numeric/meta.c
Numeric/meta.h
numarray/meta.c
numarray/meta.hMy initial idea was to add the meta.* files to the Numeric/numarray include
files, but I did not try yet to solve the problem of the
PyArray_API PY_ARRAY_UNIQUE_SYMBOL defines in the same way (I am sure
it can be done.
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Hi,
I just did a cvs update, and tried to build. wxGTK built OK, but trying to build wxPython, I get:
If this is just a blip, I'll try updating an building again soon.
(recent Gentoo Linux.)
src/gtk/_core_wrap.cpp: In function `int wxKeyEvent_GetUnicodeKey(wxKeyEvent*)
':
src/gtk/_core_wrap.cpp:1275: error: `GetUnicodeKey' undeclared (first use this
function)
src/gtk/_core_wrap.cpp:1275: error: (Each undeclared identifier is reported
only once for each function it appears in.)
src/gtk/_core_wrap.cpp: In function `PyObject*
_wrap_Window_SetBestFittingSize(PyObject*, PyObject*, PyObject*)':
src/gtk/_core_wrap.cpp:22363: error: `SetBestFittingSize' undeclared (first use
this function)
src/gtk/_core_wrap.cpp: In function `PyObject*
_wrap_Window_InvalidateBestSize(PyObject*, PyObject*, PyObject*)':
src/gtk/_core_wrap.cpp:22901: error: `InvalidateBestSize' undeclared (first use
this function)
src/gtk/_core_wrap.cpp: In function `PyObject*
_wrap_Window_GetBestFittingSize(PyObject*, PyObject*, PyObject*)':
src/gtk/_core_wrap.cpp:22927: error: `GetBestFittingSize' undeclared (first use
this function)
src/gtk/_core_wrap.cpp: In function `PyObject*
_wrap_Window_SetMinSize(PyObject*, PyObject*, PyObject*)':
src/gtk/_core_wrap.cpp:23552: error: `SetMinSize' undeclared (first use this
function)
src/gtk/_core_wrap.cpp: In function `PyObject*
_wrap_Window_SetMaxSize(PyObject*, PyObject*, PyObject*)':
src/gtk/_core_wrap.cpp:23584: error: `SetMaxSize' undeclared (first use this
function)
src/gtk/_core_wrap.cpp: In function `PyObject*
_wrap_SizerItem_GetMinSizeWithBorder(PyObject*, PyObject*, PyObject*)':
src/gtk/_core_wrap.cpp:34109: error: `GetMinSizeWithBorder' undeclared (first
use this function)
error: command 'gcc' failed with exit status 1
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris Barker wrote:
Hi,
I just did a cvs update, and tried to build. wxGTK built OK, but trying to build wxPython, I get:
If this is just a blip, I'll try updating an building again soon.
(recent Gentoo Linux.)
src/gtk/_core_wrap.cpp: In function `int wxKeyEvent_GetUnicodeKey(wxKeyEvent*)
':
src/gtk/_core_wrap.cpp:1275: error: `GetUnicodeKey' undeclared (first use this
function)
src/gtk/_core_wrap.cpp:1275: error: (Each undeclared identifier is reported
only once for each function it appears in.)
src/gtk/_core_wrap.cpp: In function `PyObject*
_wrap_Window_SetBestFittingSize(PyObject*, PyObject*, PyObject*)':
src/gtk/_core_wrap.cpp:22363: error: `SetBestFittingSize' undeclared (first use
this function)
src/gtk/_core_wrap.cpp: In function `PyObject*
_wrap_Window_InvalidateBestSize(PyObject*, PyObject*, PyObject*)':
src/gtk/_core_wrap.cpp:22901: error: `InvalidateBestSize' undeclared (first use
this function)
src/gtk/_core_wrap.cpp: In function `PyObject*
_wrap_Window_GetBestFittingSize(PyObject*, PyObject*, PyObject*)':
src/gtk/_core_wrap.cpp:22927: error: `GetBestFittingSize' undeclared (first use
this function)
src/gtk/_core_wrap.cpp: In function `PyObject*
_wrap_Window_SetMinSize(PyObject*, PyObject*, PyObject*)':
src/gtk/_core_wrap.cpp:23552: error: `SetMinSize' undeclared (first use this
function)
src/gtk/_core_wrap.cpp: In function `PyObject*
_wrap_Window_SetMaxSize(PyObject*, PyObject*, PyObject*)':
src/gtk/_core_wrap.cpp:23584: error: `SetMaxSize' undeclared (first use this
function)
src/gtk/_core_wrap.cpp: In function `PyObject*
_wrap_SizerItem_GetMinSizeWithBorder(PyObject*, PyObject*, PyObject*)':
src/gtk/_core_wrap.cpp:34109: error: `GetMinSizeWithBorder' undeclared (first
use this function)
error: command 'gcc' failed with exit status 1
Looks to me like a previous install of wxGTK is being used. Did you do a "make install" in the wxGTK build dir? If you did install, is that wx-config the one that is found by setup.py? If no then you can use WX_CONFIG on the setup.py command line to set which wx-config script it will use. Also, if you don't want to install your build of wxGTK then you can use WX_CONFIG="/path/to/wxbuild/dir/wx-config --inplace"
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Chris Barker wrote:
Robin et al,
There's been some discussion lately over on the NumPy list about using
the new numarray package with wxPython. It was found that using
numarrays with wx.DC.DrawLines (for instance) was much slower than using
Numeric arrays. This is mostly a numarray problem, but in the discussion
it has come up that it would obviously be much faster if numarrays
(and/or Numeric arrays) could be accessed directly by wxPython. The
Numarray folks have come up with a PEP (enclosed) about including just the headers of numarray in the standard Python distribution to make this easier, but in the meantime, I think you could have some incite into he rest of the discussion that has ensued, mostly between Todd Miller, the lead numarray developer, and Tim Hochberg, whom you know.Below is a summary, the whole thread is here:
http://sourceforge.net/mailarchive/message.php?msg_id=8835428
Actually some of the thread, the threaded view doesn't seem to be
working well.
Thanks for the info, I'll try to find time to get up to speed on the conversation. In a nutshell though, I am in favor of anything that improves speed in the specialty cases as long as there is no impact in the common cases.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!