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

Rust Language Binding #305

Open
Sir-NoChill opened this issue Mar 8, 2024 · 16 comments
Open

Rust Language Binding #305

Sir-NoChill opened this issue Mar 8, 2024 · 16 comments

Comments

@Sir-NoChill
Copy link

I'm looking to contribute a rust language binding for PKL, I was wondering if anyone had already started on one after finding this discussion.

@Sir-NoChill
Copy link
Author

Current repository. I'm essentially duplicating the pkl-go repository and translating to rust.

@stackoverflow
Copy link
Contributor

Inded pkl-go is a good example for you to base your implementation on.
Also, take a look here for the message passing specification.

@mmbarness
Copy link

Interested in contributing. I'll take a look.

@holzensp
Copy link
Contributor

holzensp commented Mar 12, 2024

As far as I know @jackkleeman was looking at this also, but I don't know whether he made a start anywhere.

@jackkleeman
Copy link

Go for it - not started anything. Translating the go repo is a solid strategy

@Sir-NoChill
Copy link
Author

Do we need to encode the field names in the message passing standard? I am assuming yes, since it would be hard for pkl to guess positional arguments in something like

[
  0x20,
  {
    "file:",
    true,
    true,
  }
]

For context, I'm attempting to use the rmp_serde package to serialize the messages, but I'm not sure how to force it to encode field names, so if anyone has any ideas or experience that would be mighty helpful.

@jackkleeman
Copy link

https://pkl-lang.org/main/current/bindings-specification/index.html might be some info here?

@Sir-NoChill
Copy link
Author

That's the page that prompts my question, I'm going to assume messages need to be formatted more or less exactly the same as what's shown unless there is evidence to suggest otherwise.

@Sir-NoChill
Copy link
Author

Including for posterity sake that I managed to figure it out. See the corresponding issue in my repo.

@Sir-NoChill
Copy link
Author

Does anyone know if there is a way to get the pkl server to read input from a fifo or some other method of IPC? I'm trying to debug my communications between the rust program and the server and am having some difficulties.

@jackkleeman
Copy link

I think it just reads stdin, but you should be able to exec the process using any file as stdin, including a fifo?

@z-jxy
Copy link

z-jxy commented Jun 13, 2024

If any references are still needed for this, I have a rust binding https://github.com/z-jxy/rpkl

@Sir-NoChill
Copy link
Author

If any references are still needed for this, I have a rust binding here: https://github.com/z-jxy/pkl-rs

I don't think that is public

@z-jxy
Copy link

z-jxy commented Jun 14, 2024

If any references are still needed for this, I have a rust binding here: https://github.com/z-jxy/pkl-rs

I don't think that is public

Sorry link didn't paste right, should work now

@Sir-NoChill
Copy link
Author

Sir-NoChill commented Jun 27, 2024

Alright, so I think I'm going to try to pull your codegen into my repo. Hecktic couple weeks, so sorry for the absence of activity.

Currently I am working on making the binding documentation a bit more robust and refining the API so that everything works well. @z-jxy what's your plan with your repo? I'm very open to the suggestion that my binding is a bit over-engineered for the moment, so I'm open to switching the bulk of the work to yours to make everything work there.

I also made a repo for illustrative purposes that uses my bindings here (I'll pin the version in the cargo).

@z-jxy
Copy link

z-jxy commented Jun 27, 2024

@Sir-NoChill I was planning to publish the crate after adding some more documentation and reorganizing some of the modules.

Also wanted to focus on improving the codegen since it doesn't provide much flexibility at the moment. For example, there's no way to specify derive attributes for generated structs. All attributes have to be added manually which could be time consuming for larger modules.

I made an issue for this here.

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

6 participants