Streams wrapped please

wxPython Users
1

Robin,

Could you please include the following classes in the SWIG
wrappers? They are needed if you are working with images,
and want to keep stuff mostly in memory, and/or writing
ImageHandlers.

wxDataInputStream
wxDataOutputStream
wxFileStream
wxFileInputStream
wxFileOutputStream
wxMemoryInputStream
wxMemoryOutputStream
wxTextInputStream
wxTextOutputStream

None of them are critical since they can all be duplicated by
code written in Python, but it sure feels like a waste of
time spending several hours reimplementing something that
already exists.

Roger

2

There is also an omission in the wrapped InputStream base class.
The method Read() is not wrapped. Makes it very hard to
work with when dealing with more than a byte at a time :slight_smile:

Roger

3

Roger Binns wrote:

Robin,

Could you please include the following classes in the SWIG
wrappers? They are needed if you are working with images,
and want to keep stuff mostly in memory, and/or writing
ImageHandlers.

wxDataInputStream
wxDataOutputStream
wxFileStream
wxFileInputStream
wxFileOutputStream
wxMemoryInputStream
wxMemoryOutputStream
wxTextInputStream
wxTextOutputStream

None of them are critical since they can all be duplicated by
code written in Python, but it sure feels like a waste of
time spending several hours reimplementing something that
already exists.

The Python wrappers for wxInputStream are designed to be able to delegate to any Python "file-like" object, to allow the Python stream objects to be used where wxInputStreams are needed. The same could be done with wxOutputStream, but nobody has asked for it until now.

I don't really see the need to do wrappers for the specialized stream classes, but if somebody wants to do the work I don't mind adding them.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

4

Roger Binns wrote:

There is also an omission in the wrapped InputStream base class.
The method Read() is not wrapped. Makes it very hard to
work with when dealing with more than a byte at a time :slight_smile:

Because it implements the Python "file-like object" interface instead. In addition to some of the wxInputStream methods, the "file-like" methods available are:

     void close();
     void flush();
     bool eof();
     PyObject* read(int size=-1);
     PyObject* readline(int size=-1);
     PyObject* readlines(int sizehint=-1);
     void seek(int offset, int whence=0);
     int tell();

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

5

I don't really see the need to do wrappers for the specialized stream
classes, but if somebody wants to do the work I don't mind adding them.

I did discover afterwards that the file like methods were present on
wxInputStream but couldn't tell if it was because something like
multiple inheritance was happening from the file object I passed in
or if they were natively implemented on top of the wxWindows object
itself. (ie I couldn't tell if an InputStream object created in
wxPython was identical to one created within the bowels of the
wxWindows library, with things like the pythonic read/readline etc
only on the former).

OutputStream will be needed to be wrapped in some way as well
to write an ImageHandler. It would also be nice to have the
SaveFile methods in wxImage taking an OutputStream being wrapped.

Currently working with images in wxPython requires the use
of temporary files when doing things like format conversions.

I would also recommend updating the doc for wxInputStream to
point out exactly how it is wrapped, and how you can use that
wrapper with file objects (including StringIO) to replace
all the other builtin InputStreams (except Data and Text streams).

Roger

6

Because it implements the Python "file-like object" interface instead.
In addition to some of the wxInputStream methods, the "file-like"
methods available are:

There is another "bug" in the wrapping of wx.FSFile.__init__.
The first parameter (after self) is supposed to be an InputStream.
However I passed in a file like object (cStringIO.StringIO) which
it gladly accepted until several stack frames later when NULL
was dereferenced as an InputStream class and the whole process
coredumped.

Roger

7

Roger Binns wrote:

OutputStream will be needed to be wrapped in some way as well to write an ImageHandler.

It's on the TODO.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

8

Roger Binns wrote:

Because it implements the Python "file-like object" interface instead.
In addition to some of the wxInputStream methods, the "file-like"
methods available are:

There is another "bug" in the wrapping of wx.FSFile.__init__.
The first parameter (after self) is supposed to be an InputStream.
However I passed in a file like object (cStringIO.StringIO) which
it gladly accepted until several stack frames later when NULL
was dereferenced as an InputStream class and the whole process
coredumped.

Please send a small sample.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

9

There is another "bug" in the wrapping of wx.FSFile.__init__.
The first parameter (after self) is supposed to be an InputStream.
However I passed in a file like object (cStringIO.StringIO) which
it gladly accepted until several stack frames later when NULL
was dereferenced as an InputStream class and the whole process
coredumped.

Please send a small sample.

Will you accept gdb output? To provoke this you have to have a
FileSystemHandler that returns an image which is quite a bit
of code to hack out of my project. I was getting crashed
interpretters on Windows but couldn't figure out what was
going on since the debugger with mingw displays a work of
fiction as the stack trace.

I installed the source rpm of the current wxPython (NOT the
Gtk2 version) and editted the spec file to add --enable-debug
to configure and a line to prevent the stripping of symbols.
This is the session (with some noise lines omitted) (there
were 97 stack frames for example):

Segmentation fault (core dumped)
rb.com rogerb /space/bitpim > gdb /usr/bin/python core.31971
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)...
Core was generated by `python bp.py'.
Program terminated with signal 11, Segmentation fault.
#0 0x406421bb in wxImageHandler::CallDoCanRead(wxInputStream&) (this=0x8236d98, stream=@0x8bed100)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/common/image.cpp:1432
1432 off_t posOld = stream.TellI();
(gdb) bt
#0 0x406421bb in wxImageHandler::CallDoCanRead(wxInputStream&) (this=0x8236d98, stream=@0x8bed100)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/common/image.cpp:1432
#1 0x4064417f in wxImageHandler::CanRead(wxInputStream&) (this=0x8236d98, stream=@0x8bed100)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/include/wx/image.h:56
#2 0x4064169e in wxImage::LoadFile(wxInputStream&, long, int) (this=0xbfffb780, stream=@0x8bed100, type=50, index=-1)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/common/image.cpp:1193
#3 0x4063d487 in wxImage (this=0xbfffb780, stream=@0x8bed100, type=50, index=-1)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/common/image.cpp:124
#4 0x407151e9 in wxHtmlImageCell (this=0x8bd6e78, window=0x8b25390, input=0x8bd70a8, w=-1, h=-1, scale=1, align=8,
    mapname=@0xbfffb9f0) at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/html/m_image.cpp:431
#5 0x40716cfc in HTML_Handler_IMG::HandleTag(wxHtmlTag const&) (this=0x8b16148, tag=@0x8bc54e0)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/html/m_image.cpp:652
#6 0x4070142c in wxHtmlParser::AddTag(wxHtmlTag const&) (this=0x8b25580, tag=@0x8bc54e0)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/html/htmlpars.cpp:321
#7 0x40701376 in wxHtmlParser::DoParsing(int, int) (this=0x8b25580, begin_pos=370, end_pos=450)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/html/htmlpars.cpp:305
#8 0x4070147e in wxHtmlParser::AddTag(wxHtmlTag const&) (this=0x8b25580, tag=@0x8c7b418)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/html/htmlpars.cpp:328
#9 0x40701376 in wxHtmlParser::DoParsing(int, int) (this=0x8b25580, begin_pos=455, end_pos=681)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/html/htmlpars.cpp:305
#10 0x4070147e in wxHtmlParser::AddTag(wxHtmlTag const&) (this=0x8b25580, tag=@0x8bcb6d8)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/html/htmlpars.cpp:328
#11 0x40701376 in wxHtmlParser::DoParsing(int, int) (this=0x8b25580, begin_pos=686, end_pos=687)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/html/htmlpars.cpp:305
#12 0x40702da3 in wxHtmlTagHandler::ParseInner(wxHtmlTag const&) (this=0x8b278a8, tag=@0x8ba85e8)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/include/wx/html/htmlpars.h:228
#13 0x4071fb5b in HTML_Handler_TABLE::HandleTag(wxHtmlTag const&) (this=0x8b278a8, tag=@0x8ba85e8)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/html/m_tables.cpp:564
#14 0x4070142c in wxHtmlParser::AddTag(wxHtmlTag const&) (this=0x8b25580, tag=@0x8ba85e8)
    at /space/rpm/BUILD/wxPythonSrc-2.4.2.4/src/html/htmlpars.cpp:321
#15 0x40701376 in wxHtmlParser::DoParsing(int, int) (this=0x8b25580, begin_pos=695, end_pos=1827)
---Type <return> to continue, or q <return> to quit---q
(gdb) l
1427 return FALSE;
1428 }
1429
1430 bool wxImageHandler::CallDoCanRead(wxInputStream& stream)
1431 {
1432 off_t posOld = stream.TellI();
1433 if ( posOld == wxInvalidOffset )
1434 {
1435 // can't test unseekable stream
1436 return FALSE;
Current language: auto; currently c++
(gdb) p stream
$1 = (wxInputStream &) @0x8bed100: {<wxStreamBase> = {_vptr.wxStreamBase = 0x0, m_lastcount = 0,
    m_lasterror = wxSTREAM_NO_ERROR}, m_wback = 0x0, m_wbacksize = 0, m_wbackcur = 0}
(gdb) q

Roger

10

Roger Binns wrote:

There is another "bug" in the wrapping of wx.FSFile.__init__.
The first parameter (after self) is supposed to be an InputStream.
However I passed in a file like object (cStringIO.StringIO) which
it gladly accepted until several stack frames later when NULL
was dereferenced as an InputStream class and the whole process
coredumped.

Please send a small sample.

Will you accept gdb output?

Yes, but in this case it doesn't help very much. I really need live code to fiddle with to be able to track down the source of the problem.

···

To provoke this you have to have a
FileSystemHandler that returns an image which is quite a bit
of code to hack out of my project. I was getting crashed
interpretters on Windows but couldn't figure out what was
going on since the debugger with mingw displays a work of
fiction as the stack trace.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!