5,321 karma · joined September 19, 2010
The sun.reflect.ReflectionFactory class only supports deserialization of objects whose classes implement java.io.Serializable
That is, you'll still be able to mutate final fields using the ReflectionFactory class, as long as that class inherits from Serializable [Speculative optimizations] may not suffice in this case as future planned optimizations may wish to rely not only on immutability within the lifetime of the process, but also on the immutability of fields from one run of the application to the next.
Can someone elaborate a little more on what this means? I'm very surprised to hear that this was considered a blocker important enough to add all of this complicated machinery (and breaking several deserialization libraries...), when I've never even heard of such an optimization and can't imagine what sort of form it would take The good news is that development could easily be funded by donations. It's only a few million. Enough to keep a few dozen people employed.
Huh? Mozilla currently spends $260M on browser development, of which >90% is salaries. Where are you getting this "it's only a few million" idea from?So—just out of this subset of expenses, there's probably some other stuff you could take issue with—Mozilla spent money in a 94% ratio on browser development, and 6% on "other stuff", of which probably .001% was this conference in Africa. And I think it's arguable that a lot of that "other stuff" is related technology! But even ignoring that, talking about how we can use the open web to improve life for people in third world countries is exactly the kind of thing that I, personally, would like Mozilla to be doing. And I'm happy for them to spend <5% of their budget on it.
https://developers.google.com/static/photos/images/picker-pi...
They also clarify this in the documentation: "Albums, favorites, and other common photos categories are not show [sic] directly. Users can search for photos using various criteria, such as keywords, dates, locations, and album titles"
The user can search for album names, but only the images from those albums are shown, and users can only select individual images. In the screenshots, you can also see that it shows that you can only select up to 2000 images. And you can see in the docs that only Image, Video and Motion type files are returned—there's no album reference that you can grab, and the URLs for these files expire after 60 minutes: https://developers.google.com/photos/picker/guides/media-ite...
The latest response from the Chromium team (https://issues.chromium.org/issues/390229583#comment20) seems to take a different approach from your comment, and says that you should think of it as a streaming response where the connection failed partway through, which feels reasonable to me, except for the fact that `await`ing the response doesn't seem to trigger any errors: https://issues.chromium.org/issues/390229583#comment21
Even just having a web-accessible endpoint that reproduced the issue would have made the process a lot smoother I think. Apparently in response to OP's request for an easier test case, OP asked for GCP cloud credits(?) to host their server with?. You probably used more bandwidth & CPU loading the new Chromium issue tracker page then you would have just setting up a simple vps to reproduce the issue
Has there been any effort taken to reduce data leakage of this test set? Sounds like these exercises were available on the internet pre-2023, so they'll probably be included in the training data for any modern model, no?