1. Using native euphoria in edbi
- Posted by jimcbrown (admin) Oct 15, 2009
- 1188 views
Forked from Re: eDBI is born, feedback wanted
Ok, so for the time being I've modified edbi.e to allow one to specify either a dll or a set of routine ids. So now I can just include edbi_eusql.e directly in example_2.ex, and create a list of routine ids, and it just works.
Is there a reason why this is disallowed? I understand that making and using a DLL is faster and more portable (drivers can be written in pure C), but the hassles of having to though translation each time to debug the library is a ... well, a hassle.
When writing a edbi driver in euphoria, it's a lot faster to debug problems when just including the driver's euphoria code directly. (If testing multiple drivers natively, just use namespaces to avoid conflicts.)
Here is the diff for the changes I made to allow using edbi_eusql natively: http://euphoria.pastey.net/126630
I discovered a bug in edbi_eusql.e, edbi_next() should take two paramenters (dbr and row) but only took one.
The diff file contains this one-liner as well.
2. Re: Using native euphoria in edbi
- Posted by jeremy (admin) Oct 15, 2009
- 1189 views
Ok, so for the time being I've modified edbi.e to allow one to specify either a dll or a set of routine ids.
Is there a reason why this is disallowed? I understand that making and using a DLL is faster and more portable (drivers can be written in pure C), but the hassles of having to though translation each time to debug the library is a ... well, a hassle.
When writing a edbi driver in euphoria, it's a lot faster to debug problems when just including the driver's euphoria code directly. (If testing multiple drivers natively, just use namespaces to avoid conflicts.)
I can see how this is helpful for development, yes. The end goal of using a DLL/SO as the driver code was not really for speed or convenience it was to give any user of eDBI the ability to load multiple drivers at runtime, drivers they may not even know exists at the time or are added to the eDBI package later on than their development period.
This can still be done if the user is willing to download and compile in various Euphoria libraries, which, as you found today with eusql, was a pain as well, albeit maybe not as much of one.
Anyway, I'm not closed at all to the ability to specify routine_id's for Euphoria code vs. writing a C wrapper but I think in almost all cases a native C binary would be a much better option. EuSQL is probably the only one that has to be written in Euphoria directly. Things like ODBC, MySQL, PostgreSQL, SQLite, Oracle, etc... would be far better as native C.
Also bear in mind that the only people that have to go through your issue are those who actually develop a new DBI driver. Users of the library will probably never venture into the individual driver code.
Jeremy
