Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support extensions #27

Open
judah opened this issue Jul 13, 2016 · 2 comments
Open

Support extensions #27

judah opened this issue Jul 13, 2016 · 2 comments

Comments

@judah
Copy link
Collaborator

judah commented Jul 13, 2016

Extensions (proto2-only) currently aren't supported yet. It's not clear what the API should look like.

This would primarily be useful for legacy code, since proto3 replaces extensions with the Any type (#22).

@gleber
Copy link

gleber commented Jun 16, 2017

Judah, have you given any thoughts about this feature?

@judah
Copy link
Collaborator Author

judah commented Jun 19, 2017

I haven't really had a chance to consider it in detail. Here's a potential approach which is along the same lines as other language bindings:

First, define an analogue RawMessage of google::protobuf::Message, which essentially holds the raw tagged values in a Map.

Now, suppose we have the following code in foo.proto:

// File foo.proto
message Foo {
    extensions 100 to 199;
}

We add a new field to Foo with name _Foo__extensions and type RawMessage. (This approach would also essentially solve #29.)

Finally, suppose we have in bar.proto:

extend Foo {
   optional int32 bar = 123;
}

message Baz {
    extend Foo {
        optional Baz foo_ext = 124;
    }
}

Then we define two new instances of Lens.Label.HasLens: HasLens "bar" f Foo Foo Int32 Int32, and HasLens "foo_ext" f Foo Foo Baz Baz; where the implementation of each lens uses the RawMessage that Foo holds.

blackgnezdo pushed a commit that referenced this issue Aug 17, 2018
* Add MNIST data to gitignore
* Add simple tensor round-trip benchmark
* Use deepseq + cleaner imports
* Use safe version of fromIntegral in FFI code
* Don't copy data when fetching tensors

BEFORE

benchmarking feedFetch/4 byte
time                 55.79 μs   (54.88 μs .. 56.62 μs)
                     0.998 R²   (0.997 R² .. 0.999 R²)
mean                 55.61 μs   (55.09 μs .. 56.11 μs)
std dev              1.828 μs   (1.424 μs .. 2.518 μs)
variance introduced by outliers: 34% (moderately inflated)

benchmarking feedFetch/4 KiB
time                 231.4 μs   (221.9 μs .. 247.3 μs)
                     0.988 R²   (0.974 R² .. 1.000 R²)
mean                 226.6 μs   (224.1 μs .. 236.2 μs)
std dev              13.45 μs   (7.115 μs .. 27.14 μs)
variance introduced by outliers: 57% (severely inflated)

benchmarking feedFetch/4 MiB
time                 485.8 ms   (424.6 ms .. 526.7 ms)
                     0.998 R²   (0.994 R² .. 1.000 R²)
mean                 515.7 ms   (512.5 ms .. 517.9 ms)
std dev              3.320 ms   (0.0 s .. 3.822 ms)
variance introduced by outliers: 19% (moderately inflated)

AFTER

benchmarking feedFetch/4 byte
time                 53.11 μs   (52.12 μs .. 54.22 μs)
                     0.996 R²   (0.995 R² .. 0.998 R²)
mean                 54.64 μs   (53.59 μs .. 56.18 μs)
std dev              4.249 μs   (2.910 μs .. 6.076 μs)
variance introduced by outliers: 75% (severely inflated)

benchmarking feedFetch/4 KiB
time                 83.83 μs   (82.72 μs .. 84.92 μs)
                     0.999 R²   (0.998 R² .. 0.999 R²)
mean                 83.82 μs   (83.20 μs .. 84.35 μs)
std dev              1.943 μs   (1.557 μs .. 2.614 μs)
variance introduced by outliers: 20% (moderately inflated)

benchmarking feedFetch/4 MiB
time                 95.54 ms   (93.62 ms .. 97.82 ms)
                     0.999 R²   (0.998 R² .. 1.000 R²)
mean                 96.61 ms   (95.76 ms .. 97.51 ms)
std dev              1.408 ms   (1.005 ms .. 1.889 ms)
judah added a commit that referenced this issue Aug 30, 2019
…ns. (#331)

We provide the whole proto message, rather than pulling off individual fields. The set of fields may change for different builds of proto-lens (or based on extensions, though we can't see those directly due to #27).

Internally, we save the proto message in the source file as an encoded string, and decode it into a Haskell type lazily.
avdv pushed a commit to avdv/proto-lens that referenced this issue Aug 9, 2023
…ns. (google#331)

We provide the whole proto message, rather than pulling off individual fields. The set of fields may change for different builds of proto-lens (or based on extensions, though we can't see those directly due to google#27).

Internally, we save the proto message in the source file as an encoded string, and decode it into a Haskell type lazily.
ylecornec pushed a commit to ylecornec/proto-lens that referenced this issue Feb 19, 2024
…ns. (google#331)

We provide the whole proto message, rather than pulling off individual fields. The set of fields may change for different builds of proto-lens (or based on extensions, though we can't see those directly due to google#27).

Internally, we save the proto message in the source file as an encoded string, and decode it into a Haskell type lazily.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants