Will,
Thanks. I did not mean to imply C/Invoke it is a dead project, it just
has been very inactive as far as visible changes/discussion.
Of course it's a dead project, no shame in that; I needed it when I wrote it but since then I've moved on to other things. Also, it was a lot more work to write the language bindings than I anticipated. Originally I had wanted to add bindings for every popular scripting language, but it takes a long time to write each one. Writing the actual C marshaling code and porting it to different architectures was the fun part. The problem is that things have changed so much in just a few years; can you believe that when I started it seemed like SPARC was still relevant! I would have been much better off targeting the iPhone instead but unfortunately it didn't exist at the time. I've also gotten so much better at coding since then, it pains me to look back on the source and see the lack of comments and some of the structural decisions I made.
> Hi Dwight...
>
> I don't think the project is still "alive" as such but as of this writing
> I'm still alive, so I'd be happy to help you in whatever capacity I can.
>
> First of all I restarted the subversion server.
Thanks.
> Secondly, I would love to have a new release of C/Invoke with support for
> Windows x64, (OS X Intel would be great too but is a little more of a pain),
> as well as some general clean-up and the other patches that people have sent
> in since the last release which are already checked in to subversion.
I need OS/X Intel to work with C/Invoke for a current project at work.
> I'd also like to see the project moved off of savannah onto google code as
> well; google code works really well in my experience and savannah is sort of
> bleh these days.
>
Yeah, I don't care much for savannah.
> So, if you want to start a new google code project with the latest svn
> tree, I could change the current web page to point to that project instead
> of the savannah one, and the rest would be up to you. If not I would
> eventually get around to doing it myself, but it wouldn't be instant as it's
> not a top priority for me.
>
It is a priority for me. I've committed to C/Invoke in a big way at
work, as it is the closest to what I need, and far better then
starting from scratch.
Ok, as far as project "ownership" I don't want to bump heads with you
as far such things as style and version control choices, but at the
same time I don't want to be held back as making massive changes.
See below...
I created a cinvoke project on google code.
http://code.google.com/p/cinvoke/
I added you as an owner.
But there are changes I'd like to make, and this is where I don't want
to cause conflict, so I created cinvoke-ng.
1) With your permission on cinvoke-ng I'd like to change the license
to MIT. I need cinvoke primarily for Lua, and Lua uses the MIT
license. I know, the current cinvoke license (seems to be New BSD
like) is close to the MIT license. (I'd retain you as copyright holder
for the years you mention in the text).
I can't really figure out what the difference is between the two, go right ahead.
2) Tabs in source code will be converted to spaces.
3) I'll be using mercurial rather than subversion. (I currently prefer
decentralized/distributed version control).
Funny you mention this as I've actually switched to using spaces-only and mercurial the last few years for personal projects.
4) I'll be making a lot of additions/changes to the Lua binding.
5) I'll want the liberty to make massive changes to the libary and
arch at my discretion.
If you're the one putting in the effort to make changes, then you have the mandate to do what you want in my opinion.
I say get rid of it, Samba did the "ng" thing and it confused the hell out of me.
I just don't want to cause conflict on the onset of of me contributing
a lot of work to an open source project.
Sincerely,
Dwight Schauer
I wish you luck in your endeavors. I wonder if it would be better to move all the existing web site html into the google code wiki. The only thing that wouldn't work for that is the generated Doxygen documentation. Of course, I don't know what your plans are concerning the C library docs, but I'll just leave them on savannah for now and we can address that if/when you want to regenerate them.