Linux-Development-Sys Digest #5, Volume #7 Wed, 28 Jul 99 22:14:07 EDT
Contents:
Re: Why ignore a theoretical possibility? (Jan Andres)
Re: Why ignore a theoretical possibility? (*puntero_loco)
__global_cli, etc. unresolved symbols (Eric Welton)
Re: OT: Affordable (was Re: when will Linux support > 2GB file size???) ("Chad
Mulligan")
Re: OT: Affordable (was Re: when will Linux support > 2GB file size???) (bill
davidsen)
Re: Why ignore a theoretical possibility? (Philip Brown)
Re: nVidia Riva TNT Drivers (max)
Re: Why ignore a theoretical possibility? (Alexander Viro)
Re: __global_cli, etc. unresolved symbols (Johan Kullstam)
Re: Why ignore a theoretical possibility? (Christopher Browne)
Ganymede 0.99.5 released (Jonathan Abbey)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jan Andres)
Subject: Re: Why ignore a theoretical possibility?
Date: 28 Jul 1999 18:42:22 GMT
In article <[EMAIL PROTECTED]>, Benedetto Proietti wrote:
| Hi,
| my name is Benedetto and I am an italian mathematics student.
| Some time ago my information science professors and I have started
| thinking about the theoretical possibility to realize a compiler like
| this:
| - a source code is compiled for the first time and some information is
| saved about it.
| - following modifications of said source could be handled so that a very
| little portion of the source is recompiled, and the generated code is
| properly inserted into the (previously) compiled file. By little portion
| I mean single functions, statement or less!
| It is obviously a non-trivial task (=design and implementation),
| nevertheless it could be done. Following recompilations are estimated to
| take about 1 tenth of sec or less.
As long as no optimization is performed, I think, compilers do no much
more than adding up pieces of machine code in the order that
statements occur in the source code.
If optimization is performed, and it is normally, then it will become
hairy. It's too much work for too few use (see below).
| My first questions to you, that surely know very well compilers and
| development systems, are:
| Question 1- Could such kind of compiler be useful to you and your job?
| Question 2- Would you use this kind of "incremental" or "real time"
| compiler?
IMO it won't be really useful. Bigger software projects are usually
split up into quite small source files. There are not many sources
that take more than ten seconds to recompile.
Once you have compiled the whole source (which will not take less time
using your compiler concept), recompiling the code after changes
usually doesn't take really much time.
If you want to spend some time on compiler development (great idea,
really! ;-), I suggest you could focus on generating code that
automatically uses multiple CPUs in a SMP system, even if the code is
not explicitly written for that purpose. This would be a quite
interesting project, as there are not many compilers that can do this,
any none for Unix AFAIK.
I'd have redirected followups to comp.lang.c, but they'll surely say
it's off-topic. :-)
--
Jan Andres [EMAIL PROTECTED] Ham radio: DH2JAN
"Emacs is WYSIWYG. What you see is text, what you get is text." --Kaz
------------------------------
From: [EMAIL PROTECTED] (*puntero_loco)
Subject: Re: Why ignore a theoretical possibility?
Date: Wed, 28 Jul 1999 21:22:13 +0200
El Mon, 26 Jul 1999 13:00:33 +0200, Benedetto Proietti <[EMAIL PROTECTED]> escribi�:
|I really thank you for the time dedicated to this idea.
|I will appreciate very much any comment to these problems, please feel
|free to answer to the newsgroup.
I think your idea is **very** interesting, not only for the theory, but also
because it may be complicated, but not imposible to make such a incremental
compiler. For example, Linux Kernel developers would thank a lot it, if you
can adds modifications to the source and recompile it in a few seconds instead
of in 10-20 minutes. I must also accelerate drastically the development of any other
huge programs or proyects.
I'm only a second course computer science engineering student (in spain), but I would
thank a lot if you keep me informed of your idea by email (you can mail me in italian
if you wish).
Juanjo.
------------------------------
From: Eric Welton <[EMAIL PROTECTED]>
Subject: __global_cli, etc. unresolved symbols
Date: Wed, 28 Jul 1999 21:47:22 GMT
DQpob3dkeSwNCg0KZ290IGFuIG9kZCBwcm9ibGVtIHcvIG15IG1vZHVsZXMuDQpJJ20gcnVu
bmluZyBSZWRIYXQgNi4wLyBrZXJuZWwgMi4yLjUsIG9uIGR1YWwgUElJLg0KSSB3aGlsZSBh
Z28gSSB3cm90ZSBzb21lIGtlcm5lbCBjb2RlICh1bmRlciAyLjApDQphbmQgYW0gaW50ZXJl
c3RlZCBpbiBwbGF5aW5nIHdpdGggaXQgYWdhaW4gKGVuIHJvdXRlDQp0byBwcm92aWRpbmcg
YSBmaWxlc3lzdGVtIHZpZXcgaW50byBhbiBSTUkgc3BhY2UgZm9yIGtpY2tzIDspDQoNCnNv
IEkgZ28gZmlndXJlIEknbGwgc2V0IHVwIGEgbmV3IHZlcnNpb24gdXNpbmcgdGhlDQpFWFRS
QV9WRVJTSU9OIHRhZyBhbmQgdGh1cyBjb21wbGV0ZWx5IGlzb2xhdGUNCm15IGRldmVsb3Bt
ZW50IGtlcm5lbCBhbmQgaXQncyBtb2R1bGVzIGZyb20gbXkNCnN0YWJsZSBlbnZpcm9ubWVu
dCAtIHNvIGZhciB0aGUgbmV3IGtlcm5lbCBib290cw0KZGFuZGlseSAtIGJ1dCB0aGUgbW9k
dWxlcyBhcmUgbm90IGhhcHB5Lg0KDQpkZXBtb2QgLWFlIGdpdmVzIG1lIHRvbnMgb2YgdG9u
cyBvZiBtZXNzYWdlcyBsaWtlLi4uLg0KDQovbGliL21vZHVsZXMvMi4yLjUtZW5peC9pcHY0
L2lwX21hc3FfdXNlci5vOiB1bnJlc29sdmVkIHN5bWJvbChzKQ0KICAgICAgICBnbG9iYWxf
YmhfbG9jaw0KICAgICAgICBzeW5jaHJvbml6ZV9iaA0KL2xpYi9tb2R1bGVzLzIuMi41LWVu
aXgvaXB2NC9pcF9tYXNxX21mdy5vOiB1bnJlc29sdmVkIHN5bWJvbChzKQ0KICAgICAgICBn
bG9iYWxfYmhfbG9jaw0KICAgICAgICBzeW5jaHJvbml6ZV9iaA0KL2xpYi9tb2R1bGVzLzIu
Mi41LWVuaXgvaXB2NC9pcF9tYXNxX3BvcnRmdy5vOiB1bnJlc29sdmVkIHN5bWJvbChzKQ0K
ICAgICAgICBnbG9iYWxfYmhfbG9jaw0KICAgICAgICBzeW5jaHJvbml6ZV9iaA0KL2xpYi9t
b2R1bGVzLzIuMi41LWVuaXgvaXB2NC9yYXJwLm86IHVucmVzb2x2ZWQgc3ltYm9sKHMpDQog
ICAgICAgIGdsb2JhbF9iaF9sb2NrDQogICAgICAgIF9fZ2xvYmFsX2NsaQ0KICAgICAgICBf
X2dsb2JhbF9zdGkNCiAgICAgICAgc3luY2hyb25pemVfYmgNCi9saWIvbW9kdWxlcy8yLjIu
NS1lbml4L2lwdjQvaXBfZ3JlLm86IHVucmVzb2x2ZWQgc3ltYm9sKHMpDQogICAgICAgIGds
b2JhbF9iaF9sb2NrDQogICAgICAgIHN5bmNocm9uaXplX2JoDQoNCg0KDQpub3cgdGhlIF9f
Z2xvYmFsX2NsaSBhbmQgc3VjaCBhcmUgZGVmaW5lZCBpbiBwbGFjZXMgbGlrZQ0KaW5jbHVk
ZS9hc20taTM4Ni9zeXN0ZW0uaCBhbmQgYXJlIGRlZmluZWQgd2hlbiBfX1NNUF9fDQppcyBk
ZWZpbmVkIC0gX19TTVBfXyBpcyBkZWZpbmVkIGR1cmluZyBib3RoIHRoZSBtYWtlIGJ6SW1h
Z2UNCmFuZCB0aGUgbWFrZSBtb2R1bGVzIHJ1bnMgLSBzbyBmYXIgc28gZ29vZC4NCg0KY2hl
Y2tpbmcgdGhlIHZtbGludXggaW1hZ2UgSSBmaW5kDQpbcm9vdEBtYWxha2FpIGxpbnV4XSMg
bm0gLW8gdm1saW51eCB8IGdyZXAgZ2xvYmFsX2NsaQ0Kdm1saW51eDpjMDEwYjk3NCBUIF9f
Z2xvYmFsX2NsaQ0Kdm1saW51eDpjMDIyN2I2MCA/IF9fa3N0cnRhYl9fX2dsb2JhbF9jbGkN
CnZtbGludXg6YzAyMmRhZjggPyBfX2tzeW10YWJfX19nbG9iYWxfY2xpDQpbcm9vdEBtYWxh
a2FpIGxpbnV4XSMNCg0Kd2hpY2ggbWF0Y2hlcyBhIGdyZXAgb24gL1N5c3RlbS5tYXAgYW5k
IHdoaWNoDQpzZWVtcyB0byBpbXBseSB0byBtZSB0aGF0IChhdCBsZWFzdCBzb21lIG9mKSB0
aGVzZQ0Kc3ltYm9scyBhcmUgYWN0dWFsbHkgZGVmaW5lZC4gIEl0J3MgYmVlbiBhIHdoaWxl
DQooYWJvdXQgMiB5ZWFycykgc2luY2UgSSBtdXR6ZWQgYXJvdW5kIGluIHRoZSBrZXJuZWws
DQphbmQgdGhpbmdzIGhhdmUgY2hhbmdlZCBhIGJpdCA7KSA7KSA7KSAtIHNvIEkgc3VzcGVj
dA0KSSdtIGp1c3QgZG9pbmcgc29tZXRoaW5nIHNpbGx5Lg0KDQphcyB1c3VhbCAtIGFueSBk
cmlibGV0cyBvZiBpbmZvcm1hdGlvbiB0b3NzZWQgdGhpcyB3YXkNCndvdWxkIGJlIG1vc3Qg
Z3JhY2lvdXMgYXBwcmVjaWF0aW9uLg0KDQpjaGVlcnMsDQoNCiAgICAtZQ0K
------------------------------
From: "Chad Mulligan" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: OT: Affordable (was Re: when will Linux support > 2GB file size???)
Date: Wed, 28 Jul 1999 15:04:57 -0700
bill davidsen wrote in message <7nnvb3$1l6g$[EMAIL PROTECTED]>...
>In article <7nliaj$[EMAIL PROTECTED]>,
>Alexander Viro <[EMAIL PROTECTED]> wrote:
>
>| ObAlphas: check the ebay. They regulary have Multias - not too
>| fast, but... 166MHz + 32Mb + SCSI - better than my development box ;-/
>| Usually they go for a hundred or so. Monitor is not a problem. So you can
>| have an Alpha box for ~$200.
>
>Are these the ones which have (a) no IDE and (b) a single channel SCSI
>controller? Actually, I said that wrong, they have a good SCSI
>controller, but it only has internal connections, there's only room and
>power capacity for one SCSI drive, and virtually no way to get a CD on
>the beast to install an OS.
>
>I passed on a model like that when the seller could provide no help in
>finding a way short of floppy to install. I guess you could do it serial
>with PPP, but it's not appealing. There was something funky about the
>net connector, DECnet in hardware or some such?
>
It's just an AUI connector.
>--
>bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
> The Internet is not the fountain of youth, but some days it feels like
>the fountain of immaturity.
>
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: OT: Affordable (was Re: when will Linux support > 2GB file size???)
Date: 28 Jul 1999 22:13:55 GMT
In article <7nliaj$[EMAIL PROTECTED]>,
Alexander Viro <[EMAIL PROTECTED]> wrote:
| ObAlphas: check the ebay. They regulary have Multias - not too
| fast, but... 166MHz + 32Mb + SCSI - better than my development box ;-/
| Usually they go for a hundred or so. Monitor is not a problem. So you can
| have an Alpha box for ~$200.
Are these the ones which have (a) no IDE and (b) a single channel SCSI
controller? Actually, I said that wrong, they have a good SCSI
controller, but it only has internal connections, there's only room and
power capacity for one SCSI drive, and virtually no way to get a CD on
the beast to install an OS.
I passed on a model like that when the seller could provide no help in
finding a way short of floppy to install. I guess you could do it serial
with PPP, but it's not appealing. There was something funky about the
net connector, DECnet in hardware or some such?
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: [EMAIL PROTECTED] (Philip Brown)
Subject: Re: Why ignore a theoretical possibility?
Reply-To: [EMAIL PROTECTED]
Date: 28 Jul 1999 22:45:47 GMT
On 28 Jul 1999 18:42:22 GMT, [EMAIL PROTECTED] wrote:
>...
>If you want to spend some time on compiler development (great idea,
>really! ;-), I suggest you could focus on generating code that
>automatically uses multiple CPUs in a SMP system, even if the code is
>not explicitly written for that purpose. This would be a quite
>interesting project, as there are not many compilers that can do this,
>any none for Unix AFAIK.
Correction: none for linux.
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
--------------------------------------------------
The word of the day is mispergitude
------------------------------
From: max <[EMAIL PROTECTED]>
Subject: Re: nVidia Riva TNT Drivers
Date: Thu, 29 Jul 1999 02:27:39 +0400
Seek there:
<http://www.nvidia.com/Products.nsf/htmlmedia/software_drivers.html>
Regards
Max
Ian Murphy wrote:
> Does anybody know where I can get X-Windows drivers for my Creative Labs
> Graphics Blaster Riva TNT 16MB AGP Graphics Card?
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: Why ignore a theoretical possibility?
Date: 28 Jul 1999 19:33:00 -0400
In article <59lnn7.76.ln@JuAnJuX>, *puntero_loco <[EMAIL PROTECTED]> wrote:
>El Mon, 26 Jul 1999 13:00:33 +0200, Benedetto Proietti <[EMAIL PROTECTED]> escribi�:
>|I really thank you for the time dedicated to this idea.
>|I will appreciate very much any comment to these problems, please feel
>|free to answer to the newsgroup.
>
>I think your idea is **very** interesting, not only for the theory, but also
>because it may be complicated, but not imposible to make such a incremental
>compiler. For example, Linux Kernel developers would thank a lot it, if you
Not.
>can adds modifications to the source and recompile it in a few seconds instead
It's called make and it doesn't take 10-20 minutes. Moreover, most of
the time on rebuild after the change falls on rechecking modification times
of the files in source tree - the thing that will be needed by any program
doing that task. What's more, the kernel relies on gcc extensions *and* on
some pretty subtle details of gcc optimizer, so other compiler is not an
option.
Now, we have less than brilliant organization of makefiles, that's
true. Recursive make is not a good idea, and there are ways to clean that
up.
Another problem (that will also be common for all tools trying to
do that) is that stuff in include/linux/* is way too coarse - typically
we #include too much and it means that there is a lot of files to recompile
upon any modification in that area. It's a double-edged thing - too fine
separation will slow the things down and create a huge mess in include/linux/*
(already pretty much overcrowded).
Try to profile the kernel rebuild and you'll see where it spends most
of the time - it will not be code generation. Recursive calls of make,
checking the timestamps and reading h-files are taking most of the time.
None of those things will be addressed by a different compiler.
>of in 10-20 minutes. I must also accelerate drastically the development of
>any other huge programs or proyects.
More or less the same situation - for real horror check WTF is
X build doing. Most of the time is spent *not* compiling the things. GNU
stuff is particulary bad in that respect - recursive make on the huge trees
is *bad* idea, especially if makefiles are way too large.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
Subject: Re: __global_cli, etc. unresolved symbols
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 28 Jul 1999 19:55:18 -0400
Eric Welton <[EMAIL PROTECTED]> writes:
> DQpob3dkeSwNCg0KZ290IGFuIG9kZCBwcm9ibGVtIHcvIG15IG1vZHVsZXMuDQpJJ20gcnVu
> bmluZyBSZWRIYXQgNi4wLyBrZXJuZWwgMi4yLjUsIG9uIGR1YWwgUElJLg0KSSB3aGlsZSBh
[snip]
wtf is this line noise?
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Why ignore a theoretical possibility?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 29 Jul 1999 00:22:01 GMT
On Wed, 28 Jul 1999 21:22:13 +0200, *puntero_loco <[EMAIL PROTECTED]>
wrote:
>El Mon, 26 Jul 1999 13:00:33 +0200, Benedetto Proietti
<[EMAIL PROTECTED]> escribi�:
>|I really thank you for the time dedicated to this idea.
>|I will appreciate very much any comment to these problems, please feel
>|free to answer to the newsgroup.
>
>I think your idea is **very** interesting, not only for the theory,
>but also because it may be complicated, but not imposible to make
>such a incremental compiler.
The question that seems to have eluded people thus far is that of
precisely *what* it is that is supposed to be "incrementally
compiled."
- I *presume* that what is being talked about is the notion of doing
incremental compilation of C code; this hasn't been made clear.
- No mention has been made of any proposed architecture of a compiler
system that would support this approach. Be aware that the
methodology is not at all consistent with the way GCC works; if the
approach is as "pseudo-intelligent" as indications would suggest, it
would require designing a completely new compiler system.
Before you start thinking about the "vast productivity increases,"
you *have* to think about the immense amount of time required to
create this new compiler system. It has taken a goodly decade for
GCC to become as mature as it is today; when you throw away all that
effort, *AS WOULD BE NECESSARY,* you introduce the need for a *HUGE*
effort.
>For example, Linux Kernel developers would thank a lot it, if you can
>adds modifications to the source and recompile it in a few seconds
>instead of in 10-20 minutes. I must also accelerate drastically the
>development of any other huge programs or proyects.
I think you misunderstand how this works.
Change 1: Minor change to kernel module.
If I make a few minor changes to a source code file in the Linux
kernel, it takes only a few seconds to type "make" and to have that
compile that source code file into object code.
This doesn't take 20 minutes; it takes 2 seconds *today.*
Linking several files into a loadable module likely takes longer
than the compilation.
Incremental compilation might cut this by 1 second. BIG DEAL.
Change 2: I make a minor change, and then want to link the kernel and
boot it.
- Recompiling the source code file takes the two seconds described
above.
- Relinking the kernel probably takes a minute.
- Installing the resultant kernel takes a minute.
- Rebooting with that new kernel takes a couple of minutes,
depending on what services I have running.
Again, the only thing that incremental compilation saves you is a
second out of a period of about 4 minutes.
Change 3: I make a highly significant change to an include file, whose
effects propagate widely.
There is no way around the 10-20 minute compile time, outside of
having Linus' quad-Xeon box that compiles the kernel in ~30s, as
there is a virtually unbounded number of bits of object code that
change as a result of this.
Result: Incremental compilation is *invalid* and *cannot be used.*
The same will be true for other complex systems.
The way of getting time savings would be to have the whole kernel be
readily reloadable without the large "waste of time" of having to
reboot the whole system.
This is one of the goals of Hurd, to have most of the code running in
user space, so that almost everything can be restarted without needing
to shut down the rest of the system.
--
If I could put Klein in a bottle...
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: Jonathan Abbey <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.admin
Subject: Ganymede 0.99.5 released
Date: 28 Jul 1999 19:13:42 -0500
Ganymede 0.99.5 is now available for download at
http://www.arlut.utexas.edu/gash2/
or
ftp://ftp.arlut.utexas.edu/pub/ganymede/
Mirrors: (may take a short while to update)
ftp://ftp.netlag.com/ganymede/ (USA)
ftp://mirror.aarnet.edu.au/pub/ganymede/ (Australia/NZ only)
ftp://ftp.kddlabs.co.jp/pub/ganymede/ (KDD R&D Labs, Saitama, Japan)
Ganymede is a GPL'ed network directory management system written in
Java, providing support for team management of NIS, DNS, etc.
--
Lots and lots of improvements. Lots.
This release includes more stability and refinement improvments than
any single Ganymede release in quite a long time. This release feels
a lot more like a 1.0 release than any other so far. It's not a 1.0
release, not quite yet, but that's because I haven't had enough
testing time on it and because there still isn't quite enough
documentation.. I think in terms of features and polish, this is very
close to 1.0.
A lot of code was changed this time, so I'm sure there may be a new
misfeature or two. Please let me know if you find any.
==================== Changes from 0.99.4 to 0.99.5 ===================
RELEASE DATE: July 28, 1999
1. [SCHEMA] Several gasharl schema mods
The commitPhase2() method in userCustom for the gasharl schema now
calls out to 'directory_namer' and 'directory_maker' to handle
external actions when users are renamed or created.
Added support for generation of the ARL maildirect file, which will be
of absolutely no interest to anyone outside of ARL.
2. [CLIENT] Fixed client behavior on catastrophic transaction commit failure
The client wasn't properly getting rid of any edit windows if a
transaction commit failed catastophically. This was occuring during
development and test of changes in 1.) above.. a NullPointerException
was causing the transaction to be aborted rather than committed, and
the client wasn't properly resetting its state to reflect this.
3. [DOCUMENTATION] Put a warning about deadlock possibilities into DBEditObject guide
The DBEditObject commitPhase1(), commitPhase2(), and release() methods
are called by the server while portions of the database are locked.
Using the GanymedeSession query mechanism will very likely bring the
server into deadlock, as I discovered. Documented this in the DBEditObject
subclassing guide, as well as the javadocs for those methods.
4. [SERVER] Revised GanymediatorWizard spec, logic
In 0.99.4 and before, the GanymediatorWizard logic depended on the
custom wizard author writing a getStartDialog() method that had to
be smart enough to unregister() itself if no further interaction
with the user was needed. It was very, very easy to not do this,
and so leave the client's GanymedeSession with a registered wizard
blocking further activities.
To prevent this problem, I have deprecated getStartDialog() in
favor of a processDialog0() method to start the wizard sequence. This
has the advantage that the GanymediatorWizard's respond() method
will automatically unregister a wizard that no longer needs to talk
to the user.
This is an incompatible change in the GanymediatorWizard class that
will break existing wizard-using custom code, but fixing this now
will make wizard use far more reliable, and it would only be harder
to fix this later.
I don't expect many (any?) folks outside of ARL have written wizards
for use with custom schemas yet. For those who are interested, the
GanymediatorWizard javadoc header now has some hopefully usable
documentation on how to do this. (I've also written a guide on
the whole subject.. see change #18.)
Modified all wizard code in all of the included schema kits (not
counting the not-maintained ganymede.only schema) to use the modern
wizard support code.
5. [SERVER] Made transaction commit, abort clear active wizard
Another fix to help keep wizards from getting stuck.. aborting or
committing a transaction will now clear any wizard from registration
with the GanymedeSession object.
6. [SERVER] Improved lock system to prevent intra-thread deadlock
Modified the DBSession and DBEditSet lock handling code to help insure
that the server can't be deadlocked by a thread attempting to
establish a lock when it already holds one that would cause the new
lock establish() to deadlock the server.
This should only be an issue in terms of deadlock brought about during
transaction commit through errors in custom-plugin development.. the
existing system already prevented deadlocks between threads. Now the
server will report an intra-thread lock error rather than simply
dead-locking.
Note that this deadlock prevention is in the form of an
InterruptedException being thrown, rather than permissive
lock-sharing.. the reason for this is that the operations that require
a read or dump lock (such as a query) will not be able to provide
transaction-consistent results when called from within a transaction
commit.
This change is entirely for the purpose of making the server more
friendly to customizers, and should not have any significant effect on
normal server operations.
7. [CLIENT] Fixed password handling in dialogs passed to the client
Wizards that asked the client for a new password value (as in the user
reactivation wizard in the gasharl schema) were not able to get a
password back because the password field logic in StringDialog and
JpassField was not working properly.
Wizards can now request a new password from the client properly.
8. [SERVER] Changed dump process to be safer
Previously, the server would dump the database by first renaming the
old on-disk database to ganymede.db.bak, and then write the current
in-memory database to ganymede.db.
This meant that if the server was killed while writing out the
database, there would be an incomplete ganymede.db file in place,
which would require the admin to manually recover from the
ganymede.db.bak file. Things would always be recoverable, but it
wasn't an automatic process.
Now, the ganymede.db file is not renamed until the server has
completed dumping out its new dump, which is called ganymede.db.new
during the dump.
There are still one very narrow opportunity for stopping the server at
a point in which the server can't recover on its own at restart, but
the odds of this occuring are infinitesimally low now.. only if the
server is killed after it has renamed ganymede.db to ganymede.db.bak
and before it has renamed ganymede.db.new to ganymede.db will the
server be unable to properly recover on start-up.
This change does slightly increase the amount of disk space needed
during operations, as the system needs to have enough disk space for
three versions of ganymede.db at a time during a database dump.
Thanks to Darrell Tippe, <[EMAIL PROTECTED]>, for reporting
the problem.
9. [SERVER] Made DBObjectBase explicitly record max object id
The Ganymede server in some cases could erroneously re-use an Invid.
This could occur if an object was deleted, and the server was
restarted before another object of that type could be created. The
server now explicitly records the maximum object id seen for
each object type in the ganymede.db file.
This change bumps the DBStore revision numbers to
major: 1
minor: 12
10. [SERVER] Seriously Improved Logging, Mailouts Systems
Reworked lots and lots code in DBLog.java, DBEditObject.java, and
DBEditSet.java to make all of the transaction logging stuff work
right.
--
Mail-related exceptions will no longer cause transactions to fail to
commit.. the server will report the mailer error, but continue with
normal processing.
--
Modified the Qstmp class so that it can queue messages for sending on
a background thread.. the extensive mail-outs in the revised logging
system was noticeably slowing down transaction commits.
All e-mail messages sent out by the DBLog class will be done without
blocking the logging thread.
--
The DBEditSet class now does transactional event logging after a
transaction's objects have had all of their commitPhase2() methods
called. This change makes it possible for a commitPhase2() method to
send mail out.
--
Added variants of DBSession.viewDBObject() that will automatically
retrieve the original version of a DBObject that is being deleted by
the current transaction. Useful for getting the original version of
an object during transaction commit from the object's Invid.
--
Added a getLabel() override to DBEditObject.java that will
automatically return the object's pre-deletion label if the
object is being deleted and the DBObject getLabel() routine
returns null.
--
Added standard methods to allow custom objects to identify email
addresses that should be notified when changes are made to them.
Useful for making sure that users get cc:'ed on any changes made to
their account, etc.
These methods are documented in the DBEditObject subclassing guide,
and are used by the logging system.
11. [CLIENT] Added tooltip support to checkboxes, other GUI field types
A number of the GUI field types supported by the clients were not
being added to containerPanel with any registered field comments set
as tooltips. Fixed.
12. [SERVER] GanymedeScheduler could lose on-demand tasks
If the Ganymede server tried to initiate an on-demand task that was
currently running, the scheduler would 'lose' the task instead of
properly doing back-to-back execution of the task. Big oops.
13. [SERVER] GanymedeBuilderTask didn't do overlap properly
The GanymedeBuilderTask base class has code that remembers the last
time the builder task was run, so that it can check for changes in
the various object bases that occurred since the last builder task
run. Unfortunately, the time stamp was being recorded after the
builder task completed, even though changes could be made in the
database after builderPhase1() finishes and before builderPhase2()
completes, which left the possiblity for build tasks to not be
re-issued properly if two transactions affecting the same object
base were committed back-to-back .
The GanymedeBuilderTask base class now properly records the time
before entering builderPhase1(), so that rapid sequences of changes to
the database will always properly trigger subsequent builds.
14. [SERVER, CLIENT, CONSOLE] Cleaned up login sequence
Both the admin console and client will now give a nice dialog if login
fails. Previously, the admin console showed an exception trace, which
did not make it clear that the problem was a bad username or password.
Made the clients include error.gif in several of their dialogs.
15. [CLIENT] Removed extraneous menu items from object windows
The object view/edit windows had a menu on them that included a number
of options that didn't always apply, as well as a 'print' option which
never worked well enough to be available to the end user.
Now, the object window's "File" menu only includes actions that can't
be done anywhere else.
The File menu will now only present the 'Set Inactivate Date' option
when the object being edited can in fact be inactivated.
16. [SERVER] Cleaned up schema dumping of persona objects
Modified DBObject and DBObjectBase's partialEmit() methods so that
supergash's locally-defined email address is not saved into the
ganymede.schema file.
17. [WEB FILES] Reworked the web access system for the Ganymede clients
Brian O'Mara did a very nice job of making a new set of web pages for
the Ganymede clients. The new primary web page uses JavaScript to
launch the clients in their own frames, making it possible to run a
client and console simultaneously, and to be able to close the
original launch frame without killing the clients.
18. [DOCUMENTATION] Added a detailed guide to Wizard authoring
Added another long document on customizing the server with plug-in code,
this time on the topic of wizard authoring.
===============================================================================
Jonathan Abbey [EMAIL PROTECTED]
Applied Research Laboratories The University of Texas at Austin
Ganymede, a free NIS/DNS management system http://www.arlut.utexas.edu/gash2
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
