Closed sheerun closed 9 years ago
Sorry, but I don't know which version works and which doesn't. I've written this project a long time ago and I'm not very active in the Ruby community any more... So I guess this project is open for adoption. Might you be interested?
Yeah, sure. I want to develop service similar for https://rails-assets.org/ for FFI bindings.
Cool! Great idea. I'll move the project to a new "ffi-gen" organisation and give you admin access, okay?
No need to. A collaborator is enough for now.
Okay, done. :-)
Awesome! ruby-llvm is a fun project, but after Richard created ffi-gen, I knew there was real potential. With enough attention, this could really be a fun, hackable, universal alternative to SWIG.
Cheers,
On Wed, Nov 12, 2014 at 4:41 PM, Richard Musiol notifications@github.com wrote:
Okay, done. :-)
— Reply to this email directly or view it on GitHub https://github.com/neelance/ffi-gen/issues/23#issuecomment-62822258.
Jeremy Voorhis
@sheerun Feel free to do any changes you like, I'll complain if necessary. ;-) But I don't think I will, I am more than grateful that you take care of the project.
Most likely my changes for ffi-gen will be cosmetic-only as for now I don't have much knowledge about llvm and low-level stuff in general. I'll try my best, tough :)
Btw. should I release ffi-gen or rename it back to ffi_gen?
As far as I remember I started with ffi_gen and then renamed it to ffi-gen since the dash is more common. But I couldn't rename it on RubyGems. What do you think is the better approach?
I think we should stay with ffi_gen, because we're not extending FFI
You could rename repo back to ffi_gen I guess.
Done. Could you take care of the file changes?
Yes, sure. But on the weekend.
On Thu, Nov 13, 2014 at 2:40 AM, Richard Musiol notifications@github.com wrote:
Done. Could you take care of the file changes?
— Reply to this email directly or view it on GitHub https://github.com/neelance/ffi_gen/issues/23#issuecomment-62827483.
@neelance I rebased whole project removing commits that changed filenames. I hope you don't mind. Old code is in old-master
branch. Do you think we can release current code? There were some fixes.
@sheerun that's in general not a wise thing to do because of people's git clones depending on the old master branch. You may run into trouble if/when those people make pull requests.
Yes, I also think that this might make (existing) pull requests more complicated. Reverting the changes or simply changing it back by hand might be better.
@mvz @neelance Existing 2 pull requests are literally 3 commits with 3 lines changed.
Those pull requests would break anyway, because of renamed files. Anyone needs to rebase anyway.
I can rebase those 3 commits or even write them by hand.
Besides, current pull requests don't include tests.
First two changes: https://github.com/DAddYE/ffi-gen/commits/patch-1 Second change: https://github.com/jvoorhis/ffi_gen/commit/79cfb0973db4ed322bc941a34e5c56995c7f0ef3
The second change is so old there's not even need for rebase.
@mvz @neelance Never mind, I rebased on old-master. It was easier than I thought. Sorry for this :)
What are the blockers for patch / minor release? What do you think?
I think #20 needs to be fixed.
@mvz This is issue with already released ffi_gen version. Let's fix it in next patch. It's not a blocker.
Hm, I guess it depends on what your release goal is, then.
To release two-year old fixes in master. One step a a time. Maybe some Travis suite before release could be helpful though.
Newest clang is 3.5.0. Could you fix the readme if you meant "At least 3.0"?