9:35 p.m.
>>>> "Mikio" == Mikio Nakajima
<minakaji(a)osaka.email.ne.jp> writes:
Mikio> From: Mikio Nakajima <minakaji(a)osaka.email.ne.jp>
Mikio> Subject: gdbm support of database.c
Mikio> Date: Sat, 02 Jan 1999 17:19:04 +0900
> I herewith attach diff files which provide a facility of
> manipulating a gdbm file. I built XEmacs linked to gdbm 1.7.1 with
> --with-database=dbm,gnudbm option. The original XEmacs 21.2b8 insists
> that dbm options conflict to gnudbm, but attached ndbm.h.diff (diff
> file of ndbm.h of gdbm 1.7.1) can avoid it.
Mikio> Too long e-mail seemed to be unhappy for you. I'm so sorry.
The right way to submit patches is to send them to xemacs-patches(a)xemacs.org.
Please read:
etc/BETA in the source distribution.
http://cvs.xemacs.org/
Mikio> Further to my work yesterday, I added to database.c three Emacs C
Mikio> primitives;
Mikio> `reorganize-database',
Mikio> `sync-database', and
Mikio> `setopt-database'
Mikio> which are respectively referred to `gdbm_reorganize', `gdbm_sync' and
Mikio> `gdbm_setopt' of gdbm library functions.
Mikio> I made tar ball named `diff-to-xemacs.21.2.8.tar.gz' which contains
Mikio> relative diffs and put it on,
Mikio> http://www.asahi-net.or.jp/~gy2m-nkjm/diff-to-xemacs.21.2.8.tar.gz
Mikio> Please note my home page index.html is Japanese only and is not
Mikio> referred to the tar ball above, so please use wget or so to get it.
Mikio> Thank you.
Mikio> Mikio Nakajima <minakaji(a)osaka.email.ne.jp>
Mikio> http://www.asahi-net.or.jp/~gy2m-nkjm/
Thank you.
However....
your patch is not likely to go in in its current state.
First of all, there is no way we can change ndbm.h. That file is
provided as part of the operating system.
configure is a generated file. You need to patch configure.in and
run autoconf (get autoconf 2.12 from ftp://ftp.xemacs.org/pub/aux)
I'm not sure we really want 3 different database types in the code (up
from two today), since this will make maintenance more difficult. All
the database functions will have to be changed someday to work better
with different text encodings. On the other hand, I am not entirely
opposed to it either. It will certainly help to clear up the configure
specification confusion we currently have.
Much of the functionality you implement is good, but should probably
be extended to other database types, Berkeley db in particular.
I suggest sync-database be renamed synchronize-database.
I suggest setopt-database be renamed set-database-property.
You probably also want to implement database-properties.
Some of your changes go against XEmacs coding conventions, like the
following:
***************
*** 629,635 ****
#endif /* HAVE_DBM */
#ifdef HAVE_BERKELEY_DB
! if (NILP (type) || EQ (type, Qberkeley_db))
{
DBTYPE real_subtype;
DB *dbase;
--- 862,868 ----
#endif /* HAVE_DBM */
#ifdef HAVE_BERKELEY_DB
! if (NILP (type) ||EQ (type, Qberkeley_db))
{
DBTYPE real_subtype;
DB *dbase;
Martin
11:11 p.m.
New subject: gdbm support of database.c
And please note I'm not a member of XEmacs mailing list (I cannot a
lot of English messages in a limited time, as I'm not a native
speaker/reader). If you have further comment, please send me
directly, too.
From: Martin Buchholz <martin(a)xemacs.org>
Subject: Re: gdbm support of database.c
Date: 03 Jan 1999 13:35:37 -0800
The right way to submit patches is to send them to
xemacs-patches(a)xemacs.org.
Yes, I will do.
First of all, there is no way we can change ndbm.h. That file is
provided as part of the operating system.
Diff for ndbm.h is only to avoid confliction between gdbm and dbm
support. If we choose we can only one of dbm or gdbm (the original
state of XEmacs 21.2b8), that's not necessary.
However, I think it's better for users to choose apply patch to a
part of an operation system. I can open both of dbm and gdbm file
with such diff. Or should I think to send patch to gdbm support
group?
configure is a generated file. You need to patch configure.in and
run autoconf (get autoconf 2.12 from ftp://ftp.xemacs.org/pub/aux)
Yes, I did. Only smart diff command picked up a change made
automatically, too. However, you didn't have to get a automatically
changes. I will never send such a change automatically made.
I'm not sure we really want 3 different database types in the
code (up
from two today), since this will make maintenance more difficult.
....
Much of the functionality you implement is good, but should probably
be extended to other database types, Berkeley db in particular.
Do people who implement new code want it works on an opetation
system he/she uses? I use Linux box (Slackware 3.5) which has glibc
1 (not includes dbm related function) and GDBM, and DOESN'T HAVE a
berkeley db. That's a normal PC UNIX user (I don't say not all PC
UNIX users are same condition).
One day, he/she found that XEmacs could open dbm file directly and
was glad to open a gdbm file made by another program of which
extention is neither .dir nor .pag... He/She wondered, why he/she
could not open the gdbm file even if he/she built XEmacs with the
--with-database=gnudbm...
It's right that a problem of maintenance you said exists. But I
cannot find out why berkeley db should have priority than gdbm...
All the database functions will have to be changed someday to work
better
with different text encodings.
I'm not sure of text encoding. But I can put Japanese text
(euc-japan encoding) to gdbm file, and get it properly to other
encoding such as iso-2022-jp or sjis. But I can get nothing (but
sometimes get XEmacs core) when gdbm file made by perl. I'm not sure
that is a problem of XEmacs, perl (Japanized version) or my patch...
I suggest setopt-database be renamed set-database-property.
Yes, I will.
You probably also want to implement database-properties.
Does it return properties which a database opened has?
Some of your changes go against XEmacs coding conventions, like the
following:
You say I should use `||EQ' instead of `|| EQ'? If so I will do.
Thank you.
Mikio Nakajima <minakaji(a)osaka.email.ne.jp>
http://www.asahi-net.or.jp/~gy2m-nkjm/
12:29 a.m.
New subject: gdbm support of database.c
>>>> "Mikio" == Mikio Nakajima
<minakaji(a)osaka.email.ne.jp> writes:
> The right way to submit patches is to send them to
xemacs-patches(a)xemacs.org.
> First of all, there is no way we can change ndbm.h. That file
is
> provided as part of the operating system.
Mikio> Diff for ndbm.h is only to avoid confliction between gdbm and dbm
Mikio> support. If we choose we can only one of dbm or gdbm (the original
Mikio> state of XEmacs 21.2b8), that's not necessary.
Mikio> However, I think it's better for users to choose apply patch to a
Mikio> part of an operation system. I can open both of dbm and gdbm file
Mikio> with such diff. Or should I think to send patch to gdbm support
Mikio> group?
Changing a file that is part of another package is simply not an
option. Even if a new version of gdbm is released with your change
applied, people will be using the old one for a long time. I think
backward compatibility for stable software must be maintained for 5
years, unless there is a very good reason not to.
Mikio> Do people who implement new code want it works on an opetation
Mikio> system he/she uses? I use Linux box (Slackware 3.5) which has glibc
Mikio> 1 (not includes dbm related function) and GDBM, and DOESN'T HAVE a
Mikio> berkeley db. That's a normal PC UNIX user (I don't say not all PC
Mikio> UNIX users are same condition).
I often write code that only works on operating systems I don't use.
It's hard.
One of the things that are hard about maintaining XEmacs is the number
of choices that users have. You could try installing Berkeley db, and
configure with different combinations of database support.
Mikio> One day, he/she found that XEmacs could open dbm file directly and
Mikio> was glad to open a gdbm file made by another program of which
Mikio> extention is neither .dir nor .pag... He/She wondered, why he/she
Mikio> could not open the gdbm file even if he/she built XEmacs with the
Mikio> --with-database=gnudbm...
Mikio> It's right that a problem of maintenance you said exists. But I
Mikio> cannot find out why berkeley db should have priority than gdbm...
Not priority. Just equal support.
> All the database functions will have to be changed someday to
work better
> with different text encodings.
Mikio> I'm not sure of text encoding. But I can put Japanese text
Mikio> (euc-japan encoding) to gdbm file, and get it properly to other
Mikio> encoding such as iso-2022-jp or sjis. But I can get nothing (but
Mikio> sometimes get XEmacs core) when gdbm file made by perl. I'm not sure
Mikio> that is a problem of XEmacs, perl (Japanized version) or my patch...
Don't work on that. It is a difficult job that requires deeper
changes to how encodings are handled in XEmacs. It is a job for me.
> Some of your changes go against XEmacs coding conventions, like
the
> following:
Mikio> You say I should use `||EQ' instead of `|| EQ'? If so I will do.
Keep the code in the same style as it is now.
Domo arigato.
Martin
1:32 a.m.
New subject: gdbm support of database.c
opening database and my code for `Fopen_database' ignores acess_
argument to open gdbm file. I will write a new code and post it to
xemacs-beta ML soon.
From: Mikio Nakajima <minakaji(a)osaka.email.ne.jp>
Subject: Re: gdbm support of database.c
Date: Mon, 04 Jan 1999 08:11:10 +0900
> You probably also want to implement database-properties.
Does it return properties which a database opened has?
New `print_database' print properly GDBM flag for opening database.
Is it possible to print further database properties to an extent of
gdbm functions?
Mikio Nakajima <minakaji(a)osaka.email.ne.jp>
http://www.asahi-net.or.jp/~gy2m-nkjm/
5:49 a.m.
New subject: gdbm support of database.c
>>>> "Mikio" == Mikio Nakajima
<minakaji(a)osaka.email.ne.jp> writes:
Mikio> I found that `print_database' does not conform to GDBM flag to use
Mikio> opening database and my code for `Fopen_database' ignores acess_
Mikio> argument to open gdbm file. I will write a new code and post it to
Mikio> xemacs-beta ML soon.
Please post patches to xemacs-patches.
Mikio> From: Mikio Nakajima <minakaji(a)osaka.email.ne.jp>
Mikio> Subject: Re: gdbm support of database.c
Mikio> Date: Mon, 04 Jan 1999 08:11:10 +0900
> > You probably also want to implement database-properties.
>
> Does it return properties which a database opened has?
Mikio> New `print_database' print properly GDBM flag for opening database.
Mikio> Is it possible to print further database properties to an extent of
Mikio> gdbm functions?
Traditionally, print_FOO prints out the most important properties of a
Lisp object type, but usually not all. So it's a matter of judgment
how many properties to print out. I'm not sure what the right answer
is here. Think about it some more. Compare with print_buffer:
(current-buffer)
==> #<buffer "reply to Mikio Nakajima">
Hmmm. Forget about implementing database-properties for now. Think
some more about it later, after implementing your other changes.
I suggested database-properties by analogy with other Lisp object
types, like event-properties and extent-properties.
Martin
7:22 a.m.
New subject: gdbm support of database.c
very much with XEmacs code and funny C syntax (I'm not a real C
programmer...).
From: Martin Buchholz <martin(a)xemacs.org>
Subject: Re: gdbm support of database.c
Date: Sun, 3 Jan 1999 21:49:31 -0800 (PST)
Please post patches to xemacs-patches.
Sorry :-p I will never forget this time.
Mikio> New `print_database' print properly GDBM flag for
opening database.
Mikio> Is it possible to print further database properties to an extent of
Mikio> gdbm functions?
Traditionally, print_FOO prints out the most important properties of a
Lisp object type, but usually not all. So it's a matter of judgment
how many properties to print out. I'm not sure what the right answer
is here. Think about it some more. Compare with print_buffer:
(current-buffer)
==> #<buffer "reply to Mikio Nakajima">
Hmmm. Forget about implementing database-properties for now. Think
some more about it later, after implementing your other changes.
I suggested database-properties by analogy with other Lisp object
types, like event-properties and extent-properties.
The following lines are forms and their evaluated results;
(setq test (open-database "~/test" 'gdbm))
--> #<database "/home/minakaji/test" (gdbm/nil/readwrite(create))
0x465b>
(set-database-property test 'fastmode t)
--> nil
test
--> #<database "/home/minakaji/test" (gdbm/nil/readwrite(create,
fastmode)) 0x465b>
(set-database-property test 'fastmode nil)
--> nil
test
--> #<database "/home/minakaji/test" (gdbm/nil/readwrite(create))
0x465b>
`set-database-property' changes fastmode option of TEST database and
we can find out by simply evaluating database object.
One of the properties we cannot see is cachesize of the database (but
we cannot get it by using a gdbm function. How to get it?). What
else properties are to be seen (either by simply evaluating object or
using a new Emacs C primitive)? This is what I want to know, but not
how to get (that is a next question). Does Berkeley db have a special
options (properties) can be set and can be seen.
Mikio Nakajima <minakaji(a)osaka.email.ne.jp>
http://www.asahi-net.or.jp/~gy2m-nkjm/
7:47 a.m.
New subject: gdbm support of database.c
>>>> "Mikio" == Mikio Nakajima
<minakaji(a)osaka.email.ne.jp> writes:
Mikio> The following lines are forms and their evaluated results;
Mikio> (setq test (open-database "~/test" 'gdbm))
--> #<database "/home/minakaji/test" (gdbm/nil/readwrite(create))
0x465b>
Mikio> (set-database-property test 'fastmode t)
--> nil
Probably you want (set-database-property db KEY VALUE) to return
VALUE, like other (set-FOO-property) functions.
Mikio> test
--> #<database "/home/minakaji/test" (gdbm/nil/readwrite(create,
fastmode)) 0x465b>
Mikio> (set-database-property test 'fastmode nil)
--> nil
Mikio> test
--> #<database "/home/minakaji/test" (gdbm/nil/readwrite(create))
0x465b>
This looks pretty good.
Mikio> `set-database-property' changes fastmode option of TEST database and
Mikio> we can find out by simply evaluating database object.
Mikio> One of the properties we cannot see is cachesize of the database (but
Mikio> we cannot get it by using a gdbm function. How to get it?). What
Mikio> else properties are to be seen (either by simply evaluating object or
Mikio> using a new Emacs C primitive)? This is what I want to know, but not
Mikio> how to get (that is a next question). Does Berkeley db have a special
Mikio> options (properties) can be set and can be seen.
If you are not interested in investigating similar options for
berkeley db, you don't need to work on it. But you are now very
qualified to do so.
Martin
9:20 a.m.
New subject: gdbm support of database.c
family now...
I have posted diff files to xemacs-patches(a)xemacs.org properly.
From: Martin Buchholz <martin(a)xemacs.org>
Subject: Re: gdbm support of database.c
Date: Sun, 3 Jan 1999 23:47:07 -0800 (PST)
Probably you want (set-database-property db KEY VALUE) to return
VALUE, like other (set-FOO-property) functions.
Ok, I will do.
This looks pretty good.
...
If you are not interested in investigating similar options for
berkeley db, you don't need to work on it. But you are now very
qualified to do so.
In Japanese this situation for me is to say, 'No se ra re te ru',
but I don't know hot to say in English...
I will be busy in business from tommorow, and I have to finish my work
on SKK (XEmacs have its earlier version as its package) in private
time for release in the near future, and more I have a project with my
friends related to PostgreSQL and Emacs..., however, I will do if I
can. That will be help to study C. Please tell me where to get
Berkeley db to work on.
Mikio Nakajima <minakaji(a)osaka.email.ne.jp>
http://www.asahi-net.or.jp/~gy2m-nkjm/
7:34 p.m.
New subject: gdbm support of database.c
On Mon, Jan 04, 1999 at 06:20:20PM +0900, Mikio Nakajima wrote:
Please tell me where to get Berkeley db to work on.
http://www.sleepycat.com/
OG.
9:58 p.m.
New subject: gdbm support of database.c
From: Olivier Galibert <galibert(a)pobox.com>
Subject: Re: gdbm support of database.c
Date: Mon, 4 Jan 1999 20:34:49 +0100
On Mon, Jan 04, 1999 at 06:20:20PM +0900, Mikio Nakajima wrote:
> Please tell me where to get Berkeley db to work on.
http://www.sleepycat.com/
I got db-2.6.4.tar.gz from the Web page.
Thanks.
Mikio Nakajima <minakaji(a)osaka.email.ne.jp>
http://www.asahi-net.or.jp/~gy2m-nkjm/
7:28 p.m.
New subject: gdbm support of database.c
>>>> "Mikio" == Mikio Nakajima
<minakaji(a)osaka.email.ne.jp> writes:
Mikio> From: Olivier Galibert <galibert(a)pobox.com>
Mikio> Subject: Re: gdbm support of database.c
Mikio> Date: Mon, 4 Jan 1999 20:34:49 +0100
> On Mon, Jan 04, 1999 at 06:20:20PM +0900, Mikio Nakajima wrote:
> > Please tell me where to get Berkeley db to work on.
>
> http://www.sleepycat.com/
Mikio> I got db-2.6.4.tar.gz from the Web page.
I suspect this is the beta version, and db-2.4.14 is the `stable'
version. Of course, XEmacs should work with both.
Martin
12:54 p.m.
New subject: gdbm support of database.c
On Sun, 03 Jan 1999 21:49:31 PST, Martin Buchholz said:
>>>>> "Mikio" == Mikio Nakajima
<minakaji(a)osaka.email.ne.jp> writes:
Mikio> I found that `print_database' does not conform to GDBM flag to use
Mikio> opening database and my code for `Fopen_database' ignores acess_
Mikio> argument to open gdbm file. I will write a new code and post it to
Mikio> xemacs-beta ML soon.
Please post patches to xemacs-patches.
Where should we send patches for "first cut, please try this and see
if it pharks up as I'm 98% sure the concept is right but the code is
almost certainly broken"?
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
9453
days inactive
9456
days old
11 comments
4 participants
participants (4)
-
Martin Buchholz -
Mikio Nakajima -
Olivier Galibert -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks