On Nov 13, 5:04 am, "Petar Petrov" <[EMAIL PROTECTED]> wrote:
> A few things. The current Python API has to remain pure-Python because some
> clients aren't able to use C/C++ extensions (like AppEngine).
> Boost is generally not accepted in Google, so a Boost::Pythonit interface
> will have to dis
I usualy can download whole manuals with this:
wget -r -k -p -F -l 0 -t 10 -nc -np http://...
-r recursive
-k convet links
-p whole page
-F force html
-l 0 number of levels (0=all)
-t 10 number of tentatives
-nc avoid links to repeated files
-np not-parent directoies
I hope this helps
Alain
Sc
you could consider wrapping protobuf-c... that will at least save you
the hassle of writing the C wrapper around C++.
- dave
On Nov 12, 10:04 am, "Petar Petrov" <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 9, 2008 at 5:14 PM, codeazure <[EMAIL PROTECTED]> wrote:
>
> > On Oct 31, 5:19 am, "Petar Petr
Sorry, the docs are not actually stored in HTML form. They are EZT
templates, so if we did make them downloadable you'd have to run an EZT web
server to view them. The best we could do otherwise would be to spider them
ourselves. So I don't think there's much worth doing here.
On Wed, Nov 12, 2
Hi -
My company works on an intranet that doesn't have an internet
connection. For 3rd-party libraries, we typically download the
documentation and host it locally. I plan to use protobuf, but I
don't see anywhere to download the docs. Any chance they'll be added
to the download package or off
I think the idea is to break up very large data sets into smaller
packets so they can be 'streamed'.
When I think of something like seismic data, stream based event
handling makes the most sense.
Can the data points be processed individually somehow, or do you need
access to all of them (in memory
You don't have to worry about the uninterpreted_option field. It's an
internal implementation detail of the parser. You should pretend it isn't
there.
The comment is saying that the uninterpreted_option field must have the name
"uninterpreted_option" in all *Options messages because the parser us
On Sun, Nov 9, 2008 at 5:14 PM, codeazure <[EMAIL PROTECTED]> wrote:
>
> On Oct 31, 5:19 am, "Petar Petrov" <[EMAIL PROTECTED]> wrote:
> > Yes, there are plans to improve performance. I have spent a little time
> on
> > this without significant improvements.
> > I think performance can hardly get
On Wed, Nov 5, 2008 at 2:53 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> [cc'ing Petar]
>
>
> On Tue, Nov 4, 2008 at 11:23 PM, DVusBoy <[EMAIL PROTECTED]> wrote:
>
>>
>> Hi,
>>
>> I have a couple of questions regarding the Python implementation.
>>
>> 1. There is a discrepancy between the functio
I was just looking over descriptor.proto for the option extensions,
and I spotted this comment that I hadn't seen before:
// Clients may define custom options as extensions of the *Options
messages.
// These extensions may not yet be known at parsing time, so the
parser cannot
// store the values
10 matches
Mail list logo