DivineTraube

The updated version gives me this (after successful setup with the example alien thing):

UnfilteredStackTrace Traceback (most recent call last) <ipython-input-2-0e20e3adf861> in <module>() 2 ----> 3 image = generate_image_from_text("alien life", seed=7) 4 display(image)

67 frames UnfilteredStackTrace: TypeError: lax.dynamic_update_slice requires arguments to have the same dtypes, got float16, float32.

The stack trace below excludes JAX-internal frames. The preceding is the original exception that occurred, unmodified.

--------------------

The above exception was the direct cause of the following exception:

TypeError Traceback (most recent call last) /content/min-dalle/min_dalle/models/dalle_bart_decoder_flax.py in __call__(self, decoder_state, keys_state, values_state, attention_mask, state_index) 38 keys_state, 39 self.k_proj(decoder_state).reshape(shape_split), ---> 40 state_index 41 ) 42 values_state = lax.dynamic_update_slice(

TypeError: lax.dynamic_update_slice requires arguments to have the same dtypes, got float16, float32.

With CDNs, there are definitely privacy (and GDPR) concerns, since often the complete traffic passes through the CDN. And in order to cache, rewrite and optimize responses, SSL connections are typically terminated in the CDN. And this implies that the CDN provider processes and potentially sees sensitive user data in plain text. Due to the distributed nature of CDNs with many edge locations, one can never be really sure what the exact legal circumstances are when user data is passed through the CDN nodes in different countries. And even though CDN providers won't leak user data on purpose, cloud bleed [1] has shown that this can happen by accident and at massive scale.

This is one of the reasons, why at Baqend we opted for a different approach: by using Service Workers, we can make sure that as a service provider we will only see public data. Personally identifiable information like cookies and sensitive session information does not leave the user's browser. And if you think about it that makes a lot of sense, since the public data really is what makes a site fast or slow. User-specific data (e.g., a profile, payment data, etc.) is hardly ever the cause of performance problems. Nonetheless, we do use CDNs for public data as they are an indispensable tool to achieve low latency.

[1] https://en.wikipedia.org/wiki/Cloudbleed