Re: Migrating from UFFI to CFFI

On Mon, 21 Oct 2013 06:13:22 +0300, Kevin Rosenberg <kevin-HJRc7zDS/[email protected]> wrote:

> On Oct 20, 2013, at 12:38 PM, Victor <[email protected]> wrote:
>> I tried to work without the clsql_uffi library on Linux (Ubuntu) and
>> will try these modifications on the "problematic" Windows 7 system
>> tomorrow. Diff for the changes is here:
>>
>> https://github.com/vityok/clsql/commit/eabede9da3e61ef5191b601dcf9b30f30f613f3e
>>
>> Actually, I would like to avoid dependencies as much as possible.
>
> Hi Victor,
>
> A quick look through your patch looks like you're on the right track.
> However, my review focused on the one problematic area I alluded to before:
> the 64-bit FFI interface. As the UFFI documentation states, there is
> a reader symbol pushed on cl:*features* for platforms that can not
> support 64-bit FFI integers. As you might expect, if 64-bit integers
> were possible on all platforms, I wouldn't have gone through the trouble
> of writing the clsql_uffi interface.
>
> Your PARSE-INTEGER approach is still viable, but would need testing and
> performance evaluation across many platforms. I don't think it is the
> best use of your time, but if it can be shown to have similar performance
> across implementations as the current code, it would be a win to not
> have an extra dependency. But, I'd estimate it to be a 20-80x use of time
> compared installing a C compiler and compiling clsql_uffi. If you
> don't wish to use Microsoft's C compiler, I imagine that mingw or possible
> gcc would work as well, but I have only used Microsoft's compiler in the
> past.
>
> For Microsoft C, I think the syntax is perhaps
>   nmake /f Makefile.msvc
> but, it has been many years since I have tried
>

Hi Kevin,

Thanks for your evaluation of the changes.

It looks like this patch does solve this problem at least on the
system where the user had it. Since the program involved in this issue
is intended to be used by just a single user, this fix is just fine
for me right now.

What if the modifications are refactored to rely on the .dll/.so/.lib
just as a fallback in case when 64 bit FFI ints are not supported? It
can cause some bit rust (since the native library will not be used in
the most cases) but at the same time it will prevent newcomers from
experiencing problems due to lack of required libraries on some
platforms (like that Windows 7).

It looks like I've generated some dirty patches over the past month, I
would like to polish them so that they can be eventually merged into
the mainline (especially the Sqlite3 autoincrement).

Thanks,
Victor