[IPython-dev] [QUAR] Re: Qt SVG clipping bug (it's NOT a matplotlib bug)- Qt won't fix...

Tue Oct 19 20:42:40 EDT 2010

Note that in the parallel code, I do exactly what you mention.
I added the buffers argument to session.send(), because it is critically
important for the parallel code to be able to send things like numpy arrays
without ever serializing or copying the raw data, and currently, I can do
that - there are zero in-memory copies of array data (even from Python->C
zmq); only over the network.  It also allows me to pickle arbitrary objects,
and send them without having to ever copy the pickled string.  Metadata is
sent via json, and on the back is a series of buffers containing any binary
data.  I imagine that my Session object will be merged with the existing
Session object once the Parallel code gets pulled into trunk, but that's a
little while off.

Perhaps with the payload system, it would make sense for the kernel to use
this new model.  Of course, it isn't perfectly universal, as web frontends
require mime-type header info in order to interpret binary data, so you
would probably fracture the portability of pure JSON, but I'm not sure.
Maybe the HTML header info can be in the JSON metadata in such a way that a
javascript side would be able to properly interpret the data.

-MinRK

On Tue, Oct 19, 2010 at 16:17, Robert Kern <robert.kern at gmail.com> wrote:

> On 2010-10-19 17:34 , MinRK wrote:
> >
> >
> > On Tue, Oct 19, 2010 at 15:05, Fernando Perez <fperez.net
> > <http://fperez.net>@gmail.com <http://gmail.com>> wrote:
> >
> >     On Sun, Oct 17, 2010 at 2:28 PM, Mark Voorhies <
> mark.voorhies at ucsf.edu
> >     <mailto:mark.voorhies at ucsf.edu>> wrote:
> >      > I tried a first pass at this (branch "pastefig" in my github
> repository.
> >      > Latest commit:
> >      >
> >
> http://github.com/markvoorhies/ipython/commit/3f3d3d2f6e1f457856ce7e5481aa681fddb72a82
> >      > )
> >
> >     Thanks!!!
> >
> >      > The multi-image bundle is sent as type "multi", with data set to
> >      > a dict of "format"->data (so, currently,
> >      > {"png" : PNG data from matplotlib,
> >      > "svg" : SVG data from maptplotlib}
> >      > )
> >      > ["multi" is probably not the best name choice -- any suggestions
> for
> >      >  something more descriptive/specific?]
> >
> >     It may be time to stop for a minute to think about our payloads.  The
> >     payload system works well but we've known all along that once we have
> >     a clearer understanding of what we need, we'd want to refine its
> >     design.  All along something has been telling me that we should move
> >     to a full specification of payloads with mimetype information (plus
> >     possibly ipython-specific extra data).  Python has a mimetype
> library,
> >     and if our payloads are properly mimetype-encoded, web frontends
> would
> >     have little to no extra work to do, as browsers are already tooled up
> >     to handle gracefully mimetype-tagged data that comes in.
> >
> >     What do people think of this approach?
> >
> >      > Naively sending PNG data causes reply_socket.send_json(repy_msg)
> >      > in ipkernel.py to hang (clearing the eighth bit of the data fixes
> this,
> >      > does ZMQ require 7bit data?) -- I'm currently working around this
> by
> >      > base64 encoding the PNG, but this may not be the best choice wrt
> >      > bandwidth.
> >
> >     That's very odd.  Brian, Min, do you know of any such restrictions in
> >     zmq/pyzmq?  I thought that zmq would happily handle pretty much any
> >     binary data...
> >
> >
> > Sorry, I sent this a few days ago, but failed to reply-all:
> >
> > It's not zmq, but json that prevents sending raw data.  ZMQ can send any
> bytes
> > just fine (I tested with the code being used to deliver the payloads, and
> it can
> > send StringIO from a PNG canvas no problem), but json requires encoded
> strings.
> >   Arbitrary C-strings are not necessarily valid JSON strings. This gets
> > confusing, but essentially JSON has the same notion of strings as
> Python-3
> > (str=unicode, bytes=C-str).  A string for them is a series of
> /characters/, not
> > any series of 8-bit numbers, which is the C/Python<3 notion. Since not
> all
> > series of arbitrary 8-bit numbers can be interpreted as valid characters,
> JSON
> > can't encode them for marshaling. Zeroing out the 8th bit works because
> all
> > 7-bit numbers /are/ valid ASCII characters (and thus also valid in almost
> all
> > encodings).
> >
> > JSON has no binary data format. The only valid data for JSON are:
> numbers,
> > encoded strings, lists, dicts, and lists/dicts of those 4 types, so if
> you want
> > to send binary data, you have to first turn it into an *encoded* string,
> not a
> > C-string.  Base64 is an example of such a thing, and I don't know of a
> better
> > way than that, if JSON is enforced. Obviously, if you used pickle
> instead, there
> > would be no problem
> >
> > This is why BSON (the data format used by MongoDB among others) exists.
> It adds
> > binary data support to JSON.
>
> The approach I advocated at SciPy was to use multipart messages. Send the
> header
> encoded in JSON (or whatever) and then follow that with a message part (or
> parts) containing the binary data. Don't try to encode the data inside any
> kind
> of markup requiring parsing, whether the format is binary-friendly or not.
> This
> lets the receiver parse just the smallish header and decide what to do with
> the
> largish data without touching the data. You don't want to parse all of a
> BSON
> message just to find out that it's a PNG when you want the SVG.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma
>  that is made terrible by our own mad attempt to interpret it as though it
> had
>  an underlying truth."
>   -- Umberto Eco
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101019/b73b1cf1/attachment.html>