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

int array -> Int32Array, bytes -> UInt8Array, float array -> Float64Array #258

Closed
bobzhang opened this issue Apr 16, 2016 · 12 comments
Closed
Labels
enhancement stale Old issues that went stale

Comments

@bobzhang
Copy link
Member

bobzhang commented Apr 16, 2016

reminder.

int array, float array -- should be easy (with a command line flag?)
bytes -- need to checking lexing runtime support

@bobzhang bobzhang added this to the prod-release milestone May 23, 2016
@bobzhang
Copy link
Member Author

same for floatArray.

there is a caveat for FloatArray.map -- in the standard api, you can not change its type

@bobzhang
Copy link
Member Author

since typedarray is an essential feature, maybe we should have a flag -bs-use-typed-array, but how does it work for some modules compiled using such flag while others not?

@bobzhang bobzhang modified the milestones: future-, prod-release Jul 21, 2016
@bobzhang bobzhang removed this from the after-4.04 milestone Aug 28, 2017
@TheSpyder
Copy link
Contributor

@bobzhang is this anywhere on the current roadmap? It has been idle for quite a few years now.

I'm considering using ocaml-protoc (which has BuckleScript support) but the representation of bytes as a number array instead of UInt8Array is not going to work.

@bobzhang
Copy link
Member Author

bobzhang commented Jun 10, 2020 via email

@TheSpyder
Copy link
Contributor

I guess "works" isn't the word I meant. I'm sure it meets the requirements, or it wouldn't be in the codebase, but slow isn't an option for me.

@chenglou
Copy link
Member

but slow isn't an option for me.

Need more of such spirit around =D

@TheSpyder
Copy link
Contributor

@chenglou I am aiming to blow some socks off when I finally release what I've been working on 😂

To be more specific about why slow isn't an option, protobuf uses byte arrays for the messages. It needs to serialize, deserialize, encode and decode to and from them constantly.

I'm using protobuf-js and some custom bindings to UInt8Array at the moment, but it would be nice to have auto-generated bindings with ocaml-protoc. That may also save some of the bundle size protobuf-js brings along for the ride.

@bobzhang
Copy link
Member Author

bobzhang commented Jun 29, 2020 via email

@TheSpyder
Copy link
Contributor

I'm not sure what you mean by For your use case, you can use your own module for UInt8Array. 🤔

I admit I haven't actually tried to use ocaml-protoc yet, this was just a flag that came up in our task to investigate it. I might start compiling it with BuckleScript and hit some other blocker. I'm scheduled to look at that in more detail in a month or so, if it looks like the way we want to go then yes I can try to make a PR.

I assume there's more to this than changing the bytes.ml implementation? Wouldn't the underlying bytes type and the %bytes_ externals need to change too?

@bobzhang
Copy link
Member Author

bobzhang commented Jun 29, 2020 via email

@TheSpyder
Copy link
Contributor

Oh interesting. Good to know, I'll keep that in mind!

@stale
Copy link

stale bot commented May 3, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale Old issues that went stale label May 3, 2023
@stale stale bot closed this as completed May 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement stale Old issues that went stale
Projects
None yet
Development

No branches or pull requests

3 participants