Lest I reinvent the wheel, I'd better ask here first:)
Has anyone worked on a Gnu Pascal interface module to Berkeley DB?
Lest I reinvent the wheel, I'd better ask here first:)
Has anyone worked on a Gnu Pascal interface module to Berkeley DB?
I've finished a near ready Free Pascal translation I had lying around. (conversion is easy, the headers are hardly 100,150 lines: I don't know how similar the header conversions are between GPC and FPC. (afaik GPC can use C headers directly?)
www.stack.nl/~marcov/bdb.zip
While converting there were two things I wasn't 100% sure off:
- "const" before a parameter in C. I assumed it only signals that the parameter is not changed in the function, not a reference like Pascal. - One function returns a (64-bit) structure. I hope that doesn't create problems. Never interfaces to C with such function.
I also don't have an app to test with atm, so it is untested.
Marco van de Voort wrote:
I don't know how similar the header conversions are between GPC and FPC. (afaik GPC can use C headers directly?)
No yet. But it can easily include little C wrappers that include the headers, and we recommend this.
While converting there were two things I wasn't 100% sure off:
- "const" before a parameter in C. I assumed it only signals that the parameter is not changed in the function,
Yes.
not a reference like Pascal.
It doesn't necessarily mean this in Pascal. That's implementation defined, and depending on the type (yes, even in BP which you're so proud to be compatible to).
In Pascal (I mean standard Pascal, not BP), `protected' means a value parameter which the function does not change, and `protected var' a reference parameter the function does not change. So, one of these should always be used for C interfaces.
- One function returns a (64-bit) structure. I hope that doesn't create problems. Never interfaces to C with such function.
No problems in GPC. Just use the appropritate type (see Programming/Data Types/Integer Types/Main Branch Integer Types in the GPC manual).
It doesn't even matter which size the types have on any platform. E.g., C's `long int' is 32 bit on some and 64 bit on other platforms. GPC's `MedInt' is always the same.
Frank
Marco van de Voort wrote:
not a reference like Pascal.
It doesn't necessarily mean this in Pascal. That's implementation defined,
[snip]
Yes I know, but language interfaces are implementation specific. Of both languages.
- One function returns a (64-bit) structure. I hope that doesn't create problems. Never interfaces to C with such function.
No problems in GPC. Just use the appropritate type (see Programming/Data Types/Integer Types/Main Branch Integer Types in the GPC manual).
It doesn't seem to be a problem in FPC either, at least not in standard mode. Maybe an artifact in my memory, or because it is 64-bit. (2* natural size)
Marco van de Voort wrote:
Marco van de Voort wrote:
not a reference like Pascal.
It doesn't necessarily mean this in Pascal. That's implementation defined,
[snip]
Yes I know, but language interfaces are implementation specific. Of both languages.
Not too much (or they shouldn't be). E.g., in C `const' has a well-defined meaning (like `protected' has in Pascal). The type sizes are usually defined by the ABI, so I don't think it's implementation specific ont he C side (otherwise, e.g., system headers couldn't be shared between different C compilers as they are on some Unix systems where GCC is not the default compiler).
On the Pascal side, it unfortunately is since Pascal was not designed for such things (I don't blame Borland this time, though they didn't actually do much to improve the situation).
`const' parameters are especially bad because AFAIK it's not very well defined in which situations they are passed by value and by reference. I think in some cases (small records?) it depends on the size of the type, i.e., it might end up being passed by value on one platform and by reference on others. (Of course, this wasn't a problem for Borland who invented this "feature" because they only supported one platform at that time.) That's why I think it's a mistake to ever use `const' parameters in an interface to C (or any other language).
- One function returns a (64-bit) structure. I hope that doesn't create problems. Never interfaces to C with such function.
No problems in GPC. Just use the appropritate type (see Programming/Data Types/Integer Types/Main Branch Integer Types in the GPC manual).
It doesn't seem to be a problem in FPC either, at least not in standard mode. Maybe an artifact in my memory, or because it is 64-bit. (2* natural size)
On some processors it is, on others it's a single word. No need to worry about in a high level language. ;-)
Frank
On Wed, Mar 20, 2002 at 06:12:35PM +0100, Frank Heckenbach wrote:
Marco van de Voort wrote:
I don't know how similar the header conversions are between GPC and FPC. (afaik GPC can use C headers directly?)
No yet. But it can easily include little C wrappers that include the headers, and we recommend this.
I'm probably a bit dim here, but surely you are not saying that it's possible to forgo rewriting the header file into a pascal interface module by `{$include wrapper.c}', are you?
Carel Fellinger wrote:
On Wed, Mar 20, 2002 at 06:12:35PM +0100, Frank Heckenbach wrote:
Marco van de Voort wrote:
I don't know how similar the header conversions are between GPC and FPC. (afaik GPC can use C headers directly?)
No yet. But it can easily include little C wrappers that include the headers, and we recommend this.
I'm probably a bit dim here, but surely you are not saying that it's possible to forgo rewriting the header file into a pascal interface module by `{$include wrapper.c}', are you?
No -- it's {$L wrapper.c}. ;-)
Of course, you still have to write wrapper.c and you need some external declarations in Pascal. For more details, you might want to look at existing interfaces such as RegEx (with the GPC sources), or the mentioned database units, etc. ...
Frank
On Thu, Mar 21, 2002 at 04:04:01AM +0100, Frank Heckenbach wrote:
Carel Fellinger wrote:
...
I'm probably a bit dim here, but surely you are not saying that it's possible to forgo rewriting the header file into a pascal interface module by `{$include wrapper.c}', are you?
No -- it's {$L wrapper.c}. ;-)
Of course, you still have to write wrapper.c and you need some external declarations in Pascal. For more details, you might want to look at existing interfaces such as RegEx (with the GPC sources), or the mentioned database units, etc. ...
I may be really really dim, but I don't see the big win. You stil have to write your own mappings from C to gpc for *all* C decl's and def's you're going to use, and specify the "assname" for all routines used. The only thing this buys you is that gpc knows what other files to compile and link when you give it the --make or --build option. Something I'm not able to use as my project's build process is to complex for this, so I've to use make anyway.
Or am I missing something here?
Carel Fellinger wrote:
On Thu, Mar 21, 2002 at 04:04:01AM +0100, Frank Heckenbach wrote:
Carel Fellinger wrote:
...
I'm probably a bit dim here, but surely you are not saying that it's possible to forgo rewriting the header file into a pascal interface module by `{$include wrapper.c}', are you?
No -- it's {$L wrapper.c}. ;-)
Of course, you still have to write wrapper.c and you need some external declarations in Pascal. For more details, you might want to look at existing interfaces such as RegEx (with the GPC sources), or the mentioned database units, etc. ...
I may be really really dim, but I don't see the big win. You stil have to write your own mappings from C to gpc for *all* C decl's and def's you're going to use, and specify the "assname" for all routines used. The only thing this buys you is that gpc knows what other files to compile and link when you give it the --make or --build option. Something I'm not able to use as my project's build process is to complex for this, so I've to use make anyway.
`gpc --automake' should now be able to cope with complex projects as well (maybe called from a makefile if you need to build other things as well).
Or am I missing something here?
Well, the main advantage is that you use the C header as it's meant to. E.g., if some "functions" declarations are actually macros (or modified by macros), the seemingly matching external declarations in Pascal won't work. (This happened, e.g., with the GMP library -- I didn't use this method there, and the interface broke with GMP 3.x.)
Another area are types. E.g., some C functions use or provide `structs', and the only thing documented about them is that they contain some fields with certain names and types. But it varies (from version to version, or system to system) where the fields are located in the `struct' and which other fields are there. So a matching Pascal `record' declaration is not possible.
Or take constants or enum values. It's not uncommon that some new values are inserted, and some of the constants change their value, in a new version.
In general, the more variation is in the library, the more problems a direct Pascal translation can have which are avoided by using C wrappers. If you only link to one specific version of one specific implementation of a library on one specific platform, you can translate it directly. But when you want to allow different versions, or not limit the program to one platform, or most of all, if there are different independant implementations of a library (e.g., libc or curses), such a direct translation is just asking for trouble.
Frank
Carel Fellinger wrote:
Lest I reinvent the wheel, I'd better ask here first:)
Has anyone worked on a Gnu Pascal interface module to Berkeley DB?
Not that I'm aware of, but Eike Lange wrote interfaces to MySQL, GNU DBM and PostgreSQL (in case this might help you), see the `Resources' web page or manual chapter.
Frank
On Wed, Mar 20, 2002 at 06:13:28PM +0100, Frank Heckenbach wrote:
Carel Fellinger wrote:
Lest I reinvent the wheel, I'd better ask here first:)
Has anyone worked on a Gnu Pascal interface module to Berkeley DB?
Not that I'm aware of, but Eike Lange wrote interfaces to MySQL, GNU DBM and PostgreSQL (in case this might help you), see the `Resources' web page or manual chapter.
That's where I looked first, I saw the MySQL and PostgreSQL files, but maybe my eye sight is really bad these days, anyhow I can't find the GNU DBM files:(, not even in the OLD directory.
The program I'm porting needs fast access to huge dictionaries, and not so much relational acces. So I thought I'd better use (G)DB. I asked for Berkeley because I read that GDB isn't supported anymore, that aside it would be fine too, and given an existing gpc interface module even a clear favourite.
The program I'm porting needs fast access to huge dictionaries, and not so much relational acces. So I thought I'd better use (G)DB. I asked for Berkeley because I read that GDB isn't supported anymore, that aside it would be fine too, and given an existing gpc interface module even a clear favourite.
I think you want to talk about GDBM. GDB is the GNU debugger. GDBM is the GNU database manager. GDBM still has a maintainer. Not much work has been done on it recently partly due to the fact it works resonably.
I have recently had reports that GDBM is faster than Sleepycat DB in some cases. If you need architecure independence, you need DB, not GDBM.
In either case, it should be a straight forward process to get access to them from gpc.
--Phil
On Wed, Mar 20, 2002 at 11:53:09AM -0800, Phil Nelson wrote:
The program I'm porting needs fast access to huge dictionaries, and not so much relational acces. So I thought I'd better use (G)DB. I asked for Berkeley because I read that GDB isn't supported anymore, that aside it would be fine too, and given an existing gpc interface module even a clear favourite.
I think you want to talk about GDBM. GDB is the GNU debugger. GDBM
Yep, stupid mistake.
is the GNU database manager. GDBM still has a maintainer. Not much work has been done on it recently partly due to the fact it works resonably.
I didn't look into it, just believed what the Debian maintainer wrote:
======> Docstring in Deb package <=============== This library is no longer supported by the FSF, and hasn't been worked on in several years -- for new applications, please consider libdb instead, and also consider migrating old applications, see /usr/doc/libgdbmg1-dev/MIGRATE.
======> /usr/doc/libgdbmg1-dev/MIGRATE.gz <====== libgdbm hasn't been maintained, and gnulibc2 has libdb included in it as the dbm-interface replacement. If you've used dbm* interfaces in your code, translation should be easy -- just stop linking with -lgdbm, -lndbm or -ldbm, and link with -ldb instead. ... _Mark_ eichin@kitten.gen.ma.us The Herd of Kittens Ex-Debian GDBM Library Maintainer 1997/6/17
Maybe things have changed since 1997, or this was never true to begin with. Anyhow, I'm not for or against gdbm, just looking for an easy way to get things going. And the portability issue is not relevant *at the moment*, but that has been the case before with this program, hence my problems porting it:)
I know this is off topic ... so this will be my last post directly on gdbm.
Maybe things have changed since 1997, or this was never true to
Yes, it was never true. gdbm-1.8.0 was released in 1999. Yes, gnulibc2 has libdb instead of gdbm. Mainly due to the fact that a) libdb has more options and b) gdbm is under the GPL, not the LGPL and I believe gnulibc2 is under the LGPL.
One other thing, gdbm has not had major new development. Don't expect a version 2.0. Although, this not an impossibility.
I'd not be opposed to writing a gpc interface to gdbm. I'd first have to get a current version of gpc on a machine.
--Phil
Carel Fellinger wrote:
On Wed, Mar 20, 2002 at 06:13:28PM +0100, Frank Heckenbach wrote:
Carel Fellinger wrote:
Lest I reinvent the wheel, I'd better ask here first:)
Has anyone worked on a Gnu Pascal interface module to Berkeley DB?
Not that I'm aware of, but Eike Lange wrote interfaces to MySQL, GNU DBM and PostgreSQL (in case this might help you), see the `Resources' web page or manual chapter.
That's where I looked first, I saw the MySQL and PostgreSQL files, but maybe my eye sight is really bad these days, anyhow I can't find the GNU DBM files:(, not even in the OLD directory.
Oh, where's it gone? :-(
Eike, any chance to bring it back?
Frank
-
Carel Fellinger -
Frank Heckenbach -
marcov＠stack.nl -
Phil Nelson