Skip to content
This repository has been archived by the owner on May 25, 2019. It is now read-only.

Rust integration #4

Closed
zetok opened this issue Jan 29, 2016 · 19 comments
Closed

Rust integration #4

zetok opened this issue Jan 29, 2016 · 19 comments

Comments

@zetok
Copy link

zetok commented Jan 29, 2016

I've looked into it a bit.

As for requirements;

implement a Rust code that somehow provides .h and uses only .h without including local Rust modules. In the future this limitation may be eliminated

There is rusty-cheddar for generating .h files from Rust files at "build" time. No idea about not including local Rust modules..?

The real problem is integration with CMake. I see no point in me spending time one learning CMake just for this, and I don't see for what other reason I could ever want to learn it.
With that in mind, there's a link to something I found that probably(?) would be helpful to someone who could want to do it: https://stackoverflow.com/questions/31162438/how-can-i-build-rust-code-with-a-c-qt-cmake-project

I guess that I could try to write some code, but I don't think that there would be any point to it, given that it wouldn't be integrated with the rest of the codebase.

@kpp
Copy link
Owner

kpp commented Jan 29, 2016

There is rusty-cheddar for generating .h files

You don't have to generate them in the first implementation. Provide implementation only.

The real problem is integration with CMake.

Do the code) I will integrate it with CMake.

No idea about not including local Rust modules..?

Each single .rs file should know nothing about other file implementations at all. Each .rs must be written as if it is the only one .rs file in this project and the other files are written in C.

@kpp
Copy link
Owner

kpp commented Jan 29, 2016

Ah. I see. I don't think it is possible to implement C++ struct in Rust, but C structs only. There is a possibility to integrate Rust only if .h are generated (to keep ABI). So it should look something like:

.rs
|  \         
.o .h      .h  .c
|    |     | \  |
|    |     |   .o
|     \    /    |
|     .hpp      |
|               |
|_____ .lib  ___|

In that case some parts of the code may be implemented either in C or in Rust. And in the future all C code will move to Rust.

But... The only way to communicate between Rust and C would be C functions. That means that you can not use Rust/C++ power inside C code.

Today my aim is to rewrite old C code into a safer C++ to make the code maintainable and testable. I try to keep the same API to run regression tests to find out whether my code works as it was expected in old toxcore.

You may use my unit tests to do the same: you write only a Rust version, generate .h, link with my tests and you are done!

No idea about not including local Rust modules..?
Both you and I must be sure we are using the same version of a function. Once you implement a Rust function you remove a C function from the project.

@quininer
Copy link

This look makes Rust code filled with unsafe? I still want it to be a pure Rust project.

@kpp
Copy link
Owner

kpp commented Jan 30, 2016

You are right, a lot of unsafe... You may make a pure Rust project based on my unit tests. When both you and me are done, C code may be eliminated. Good luck!

@kpp
Copy link
Owner

kpp commented Feb 1, 2016

@quininer You may reduce the number of unsafe if you include local Rust modules. If there is a lot of Rust code, there would be no unsafe at all, but in C bindings)

@suhr
Copy link

suhr commented Feb 5, 2016

This look makes Rust code filled with unsafe?

For a rust implementation, you can have just unsafe rust – C adapter module, and leave everything else safe.

Btw, we need C bindings for a rust implementation anyway.

@kpp
Copy link
Owner

kpp commented Feb 5, 2016

@suhr 👍

@zetok
Copy link
Author

zetok commented Feb 5, 2016

@kpp
Actually, that seems to be a bit too much overhead.

You've got some nice tests here, and I've picked applicable ones in what I did so far: https://github.com/zetok/tox + I've added a few other tests.
As I'll be implementing things in Rust, I'll most likely use ideas from other tests you've made :)

Sorry if I got your hopes up about writing C/C++/Rust kind of monstrosity, sadly, this would be a bit too far beyond what I'm capable of doing :(

What I plan on doing in my Rust implementation, is having ~pure Rust, Rust API + ~old C toxcore API for compatibility (unless they can be combined? I doubt whether that would be a good idea). C API probably will be limited to 1 file/module, as @suhr said.

@zetok zetok closed this as completed Feb 5, 2016
@ud1
Copy link
Collaborator

ud1 commented Feb 6, 2016

Whether there is a chat where it was possible to talk about development of the project? Skype/irc?

@kpp
Copy link
Owner

kpp commented Feb 6, 2016

@ud1 #2tox on Freenode

@ud1
Copy link
Collaborator

ud1 commented Feb 6, 2016

#2tox: Cannot join channel (+i) - you must be invited

@kpp
Copy link
Owner

kpp commented Feb 6, 2016

@ud1 try again

@suhr
Copy link

suhr commented Feb 6, 2016

Consider using https://gitter.im/ as a dev chat. It integrates well with gh.

@suhr
Copy link

suhr commented Feb 6, 2016

Oh, and there's some thing I think I should do.
cast @mahkoh

@mahkoh
Copy link

mahkoh commented Feb 6, 2016

As I understand it the purpose of this project is to write an implementation of the tox protocol with better documentation and higher code quality. If so then rust is probably a good language for this.

But you're putting the cart before the horses. Instead of trying to write an implementation of something that is so poorly understood (the tox protocol) you should instead try to write a specification first. Once the protocol is properly described, writing an implementation will be the easy part.

As far as I can tell, the documentation of the tox protocol is not much better now than it was in April 2014 and gentoo is probably never going to improve it. So the step forward is to either

  1. come up with your own protocol and eliminate the old toxcore implementation by dominating the market, or
  2. try to understand the protocol by reading the toxcore source code.

Number 2 will be much harder of course but guarantees compatibility with clients using the toxcore library. In any case, I'm not quite sure why I was even pinged.

@zetok
Copy link
Author

zetok commented Feb 7, 2016

@kpp thanks for the invitation to gitter, but.. no thanks. Given that it's a proprietary service, using it is a waste of time, and furthermore, loss of data. I think that you might be interested in reading https://www.mattermost.org/why-we-made-mattermost-an-open-source-slack-alternative/ which quite well shows that on an example.

Quote of the ~most relevant part, even though whole article is worthy reading:

“(…) we relied on another popular team messaging service, which became plagued with issues after it was sold to a large company. The service slowed. It froze. It crashed. It lost data. We tried to leave, but its export function broke.”

In other words, please don't fall in the trap, and if you could, please don't force other people to fall in it.

@kpp
Copy link
Owner

kpp commented Feb 8, 2016

@zetok You are dramatizing. Issues are hosted by github, CI by Travis, coverage by Coveralls. Alright, I may lose some data but who said chat messages is the data I care about?

@zetok
Copy link
Author

zetok commented Feb 8, 2016

Chat messages most of time contain very useful ideas and are one of most important sources of knowledge about the project. E.g. what won't work, or what didn't work in the past.

That basically makes them most important data, aside from the code itself. And since code is being mirrored by lots of people anyway..

You might want to organize that knowledge into FAQs and wiki pages, but even with massive amount of work in that direction it still won't cover all things that you chat about.

@suhr
Copy link

suhr commented Feb 8, 2016

There're bots for gitter, so you can sync it with IRC and save logs.
(fortunately, modern services tend to have API)

Repository owner locked and limited conversation to collaborators Feb 8, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants