will host more in depth
discussions while the user list will be
focused on user questions. The user list
should be very low bandwidth.
cheers
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation
file, it would be like running the file from
the command line.
cheers
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the
ver:[EMAIL PROTECTED]:/cvsroot/tcljava
cvs login
(just hit return for the password)
cvs checkout tcljava
Happy Hacking.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail
On Thu, 26 Oct 2000, Daniel Wickstrom wrote:
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo Are you up to it? I am going to be working on this object ref
Mo queue thing for some time, so if you could take a whack at the
Mo Notifier it would really help. There is
.in
2) configure
3) make
You don't need to. There is already a tcljava/configure file for
just that reason (so you don't need to download autoconf). If you
change the Tcl/Java configure.in file or other m4 files, you
would need to rerun things. If you wanted to do that, you
would run the ./autogen.s
a Cygwin tested build process for Tcl Blend
in the 1.2 release, but it did not support Jacl and suffered
a bit of code rot when compared to 1.3, so I had to kill it.
I need to revive that sucker, but perhaps someone else who
has done some autotools hacking would like to beat me t
ore? Perhaps
get a stack trace and print it to see where things
are going wrong.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
On Thu, 26 Oct 2000, Daniel Wickstrom wrote:
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo What version of Tcl are you using? This should not show up
Mo with Tcl 8.3.2 or 8.4. At any rate, it does not matter.
I'm using tcl version 8.3.2.
Strange, perhaps I
On Wed, 25 Oct 2000, Daniel Wickstrom wrote:
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
I'm running with the following:
redhat 6.2 tcl8.3.2 tcljava from souceforge ajuba contract
branch blackdown jdk1.1.8_v1
Mo That really should work, ever
that points to
where the Thread extension is build is the
only way to go.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED
Since I do not see this is the IBM JDK, I am going to
assume that it is a JDK 1.1.8 bug. I hear there is
also a new JDK 1.2 and JDK 1.3 from blackdown, but
I have not downloaded those for testing.
Mo DeJong
Red Hat Inc
The TclJava ma
in the most recent CVS version.
I would say this is a perfect time to try out the
new bug DB on sourceforge.
Go to:
http://sourceforge.net/projects/tcljava
The enter this in the bug tracker.
cheers
Mo DeJong
Red Hat Inc
The TclJava
% of the cases
is better than something that works for 0% of them.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word
the
[EMAIL PROTECTED] mailing list
in favor of using the ones on SF.
Same goes for the old CVS repo.
cheers
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail
one quick press of the delete button will finish
it off.
Are you up to it? I am going to be working on
this object ref queue thing for some time,
so if you could take a whack at the Notifier
it would really help. There is not going to
be much overlap in these changes, so they
can be done in pa
it with some tests under JDK 1.1
and it is working (with one small exception).
Could some folks to try this out and see if it
makes the crash in the GC thread problem go away?
There should be no more memory leaks.
The patch is for src/tclblend/tcl/lang/CObject.java
off of the contract branch.
thanks
Mo
would be better spent focusing
on that right now instead of fighting ref counting.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED
Flags.Flag DELETED] does not work, neither does
[java::field javax.mail.Flags Flag.DELETED].
I think you want to use:
java::field javax.mail.Flags\$Flag DELETED
It is a wacky hack that the Java designers decided to
throw into 1.1 so that they did not have to change the
VM spec. Rather ugly if you a
there!
Perhaps it is a problem with some init code
that is not getting run in the Tcl interp.
What part of Tcl calls those callbacks?
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe
On Thu, 12 Oct 2000, Daniel Wickstrom wrote:
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo There are two cleanup cases.
Mo TclThreadCleanup is called when a Tcl thread (one that was not
Mo started inside a JVM) is terminated. TclThreadCleanup will
Mo
On Thu, 12 Oct 2000, Daniel Wickstrom wrote:
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo What do you mean by "The jvm attach is done at the start of
Mo the thread by a registered proc"? Are you not using:
Mo (*javaVM)-AttachCurrentThread()
Tcl Blend init case, then I am all for that. Of
course, I would need to see the patch first :)
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL
Blend is loaded into
Tcl, but I am not sure what is going on when you load
Tcl Blend and Tcl into a JVM. How could we test this
sort of thing?
Here is my proposed patch to cleanup the Class refs.
I am also going to attach it to this file because
it is going to get hosed in mail.
Mo DeJong
Red Hat Inc
d info,
but it would seem to be an area that may need some work. Would
you be willing to invest some time improving the Java bean
related documentation and perhaps add an example? There was
an old bean example in version 1.0, but it was a pain
and we had no "bean expert" on the team so it w
On Mon, 9 Oct 2000, Daniel Wickstrom wrote:
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo Humm, I think so but I can't remember off hand. The problem
Mo with this "fix" is that it currently does not work. There are
Mo strange crashes when ru
ersion of your patch
into the contract branch (I just added another list command to an uplevel).
cheers
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail
e a new stop watch object and save
a reference to the Tcl object, type:
% set sw [swNew]
To set the countdown time, type:
% swSet $sw 10
Is that more clear?
Mo DeJong
Red Hat Inc
The TclJav
sg00490.html
http://www.mail-archive.com/tcljava@scriptics.com/msg00040.html
The "quick fix" (where Quick != Correct)
http://www.mail-archive.com/tcljava@scriptics.com/msg00492.html
A discussion of the real fix, and why it is hard:
http://www.mail-archive.com/tcljava@
.
You might also want to try another JVM and see if that does
anything.
By the way, why would you use that MKS Toolkit when
you could be using Cygwin?
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation
On Mon, 11 Sep 2000, Peter Geraghty wrote:
...
Peter, you are posting in HTML. This makes it very hard to
read your email. Please repost in plain text if you want
help.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored
ys welcome. Tcl/Java is an open source project,
so the more you pitch in the faster things will get done.
A number of new folks have started to contribute to the
project in recent months, and that has lead to a number
of great new features.
Mo DeJong
R
urce code for Tcl so that it can find tclInt.h.
I assume you just downloaded the binary of Tcl and you are trying to
build Tcl Blend from that. You might just want to download the binary
or Tcl Blend in that case, but be warned that the binary has its own
troubles.
M
strange JDK version that the configure script does not yet
know about. I also suggest that you use the 1.3 version in the CVS
if you are using some strange new JDK.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored
the code.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail
and reworked a bunch of stuff to support it. Things should
be fully thread safe now. If you want to take another
peek you are welcome to, of course you might have to wait
until monday morning for the CVS mirror to update.
Mo DeJong
Red Hat Inc
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL
ChangeLog
===
RCS file: /home/cvs/external/tcljava/ChangeLog,v
retrieving revision 1.59
diff -u -r1.59 ChangeLog
--- ChangeLog 2000/08/21 04:48:11 1.59
+++ ChangeLog 2000/08/23 05:51:29
@@ -1,3 +1,10 @@
+2000-08-22 Mo DeJong [EMAIL PROTECTED]
+
+
ay,
but we should fix the problem in Tcl 8.4.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as t
tor
shirt :)
I just wish we could use the garbage collector instead
of keeping that nasty Tcl_Preserve() stuff around in Jacl.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporati
er updates should be easy in comparison.
I assume that some of these changes are tested by
other tests and not just string.test.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:
ar file.
Does anyone feel up to hacking on this problem? It
would not be very hard to implement and it would
be really useful because folks could put their own
packages into .jar files. Oh, by the way in case
you are wondering how a "package require java"
works, it is faked bec
t
in a loop without increasing memory consumption (this wasn't the
fact in my first implementation!).
One would think that the Java GC system would be a bit smarter
about this. Perhaps there is ref to a slave Interp that would
need to get set to null before it could be GCed.
M
-berlin.de/~v12/krischan/clock8.4.patch
Greetings, Krischan
Checked in.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED
f using TCL.OK, what would the implications
of that be?
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBS
al tests for this are in tests/tcljava/PkgInvoker.test.
I hope that helps
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
if
we wrapped a Tcl_Obj without incrementing its ref count,
this should still work. The toString() call would
invoke Java_tcl_lang_CObject_getString which
would call Tcl_GetStringFromObj() (no problem there right).
I am sure there are cases I have overlooked,
but I think the idea is doable.
What do
onclusions. I wanted to
take my own look at the problem and see if my solution matched
yours. Now that I see we both think this is the right solution,
I feel much better about it.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sp
Here is that patch that I suggest we use to force Tcl Blend
into compiling only with threaded Tcl. This will only
appear in the contract branch for now. When that
work is merged back into the HEAD, everyone will
be forced to compile Tcl Blend with threaded Tcl.
Comments?
Mo DeJong
Red Hat Inc
nterp does not enter the event queue (like tclsh).
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the sub
On Wed, 9 Aug 2000, Scott Stanton wrote:
Mo DeJong said:
It sure would make life easier if we just required Tcl
threads to use Tcl Blend. The notifier thing would go
away because we could count on threads being there.
I'm all in favor of this. As the threaded version of Tcl becomes
On Wed, 9 Aug 2000, Jiang Wu wrote:
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 09, 2000 1:34 PM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: TclBlend Initialization Mutex
Con:
Non-thread safe extensions may have problems under
. The old JavaGetEnv method is
now called JavaInitEnv.
Jiang, what do you think? I will check it into the
contract branch if you give me the thumbs up on
this patch.
Mo DeJong
Red Hat Inc
Index: src/native/java.h
===
RCS file: /home/cvs
)-ExceptionClear(env);
return TCL_ERROR;
env can be NULL.
Doh!
Ok, I fixed that. Besides that, do you like the reorg?
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail
On 8 Aug 2000, Jiang Wu wrote:
On Tue, 08 August 2000, Mo DeJong wrote:
Ok, I fixed that. Besides that, do you like the reorg?
It looks good to me. Let's commit it to the branch.
Done and done.
Mo DeJong
Red Hat Inc
seeing 1 event getting processed in that 10 second
delay.
P.S.
I am goign to write up a better test using the test command
and a max number of queues in the second thread.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored
s not getting compiled without -D_REENTRANT or something.
That seems unlikely. Tcl Blend just uses the CFLAGS set
by Tcl.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:
ed version
of Tcl or use our special hacks. A "core patch" seems like
a bad idea if you ask me.
It sure would make life easier if we just required Tcl
threads to use Tcl Blend. The notifier thing would go
away because we could count on threads being there.
M
aVM_init_mutex);
return TCL_ERROR;
}
Any comments on this approach? I like it a bit better
than grabbing the lock before calling JavaGetEnv or
JavaSetupJava, the code seems a bit more clean with
the synchronization inside the methods.
Mo DeJong
Red Hat Inc
---
On 7 Aug 2000, Jiang Wu wrote:
On Sun, 06 August 2000, Mo DeJong wrote:
If I do 2 vwaits, then a single event is
processed from the event loop, but that seems to be all.
How did you do 2 vwaits?
-- Jiang Wu
[EMAIL PROTECTED]
Did a vwait in the callback that was added to the queue
On 7 Aug 2000, Jiang Wu wrote:
On Mon, 07 August 2000, Mo DeJong wrote:
From section 3.2 in blendchanges.txt:
load "tclblend", "tcl" .dll or .so (a)
call "new Interp()" in Java
invoke Java_tcl_lang_Interp_create() C function (b)
ca
On 7 Aug 2000, Jiang Wu wrote:
On Mon, 07 August 2000, Mo DeJong wrote:
Did a vwait in the callback that was added to the queue
in Java (see source code). Then did a normal vwait on the
command line.
I am going to try your example tonight. Is this what you mean by doing a normal
On 7 Aug 2000, Jiang Wu wrote:
On Mon, 07 August 2000, Mo DeJong wrote:
package require java
set AQT [java::new AppendEventQueueThread [java::getinterp]]
$AQT start
set orig_numQueued [java::field $AQT numQueued]
java::call AppendEventQueueThread queueVwaitEvent [java::getinterp
I ran this example, it did not deadlock in
the Notifier.queueEvent() method. Here is the
output I got:
% set orig_numQueued
0
% set numQueued
9
% set numProcessed
9
This shows that the other thread continued to
run when the main thread was inside a vwait.
Mo DeJong
Red Hat Inc
-
So, that is good as I can now reproduce the problem.
The new problem is that this bad behavior does not
seem to go away after your Notifier patch.
If I do 2 vwaits, then a single event is
processed from the event loop, but that seems to be all.
this was caused by your inter changes. Could
you double check to make sure nothing you did caused this?
I am too sleepy to do it right now. Once we get these issues
resolved, I can check in your patch, it is kind of large
so I don't want to rush on this one.
Mo DeJong
Red Hat Inc
sing are exactly the same as the example
paths, which might just be by chance.
This "init" error typically means it can not find a Java
shared lib for some reason.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by
distros have a lot of problems.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject
,
this fix should cut down the amount of memory
your application requires by quite a bit. I
don't know how much memory this will save in
a "typical application", folks are welcome
to report and positive or negative results
they get after this change.
cheers
Mo DeJong
R
That might be your best
bet, but it will only work with Tcl Blend.
http://www.neosoft.com/tclx/
I hope that helps
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to
.
Don't be afraid to download the CVS tree and rewrite any
documentation you find confusing.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
I am open to suggestions as to
how we could help people to not make this mistake in the future.
I think better documentation is the best approach, but writing docs
is boring so folks do not seem to want to help with that.
Mo DeJong
R
to
easily turn code on and off automatically (ala #ifdef) in Java.
You can use final booleans to get the same behavior, but folks
would need to go in and turn these extra checks on, so that
kind of defeats the purpose.
Mo DeJong
R
pe the system in Jacl and move to Tcl Blend
when the thread work is finished. Jacl does threads a lot better
than Tcl Blend, at least for now. You should not have to rewrite
anything, both Jacl and Tcl Blend support the same Tcl/Ja
Rajeev, you are posting in HTML. That is not allowed on this
list. Please disable HTML posting in your email client
before posting again.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation
y to debug it?
You might also want to try building tclexpat.so with stubs
support. That might work a little better.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail
.
The problems you describe sound like your env vars are not set
correctly. Try running "make shell" and then invoke "java ..."
from inside the shell, that should set up the env vars correctly.
later
Mo DeJong
Red Hat Inc
The
... A post written in HTML ...
Please do not post to the tcljava list in HTML. People
will text email clients can not read what you are posting!
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation
, it would be no big deal, but I can't see the real benefits...
I am not saying it would save the world, I just think it
would make it easier to explain the "shared code" that
is used by both Jacl and Tcl Blend. This has always been
hard to explain to new users.
Mo DeJong
Red Hat Inc
really should post a note to comp.lang.tcl about the
new stardate support in Jacl. I am sure there are lots
of people that are holding off using Jacl because
of the lack of startdate support :)
Mo DeJong
Red Hat Inc
The TclJava
- 380 code = TCL_ERROR;
- 381 goto done;
382 }
- 383 } else {
- 384 code = (*pkgPtr-initProc)(target);
385 }
It seems to want to call Tcl_PakcageInitProc. Does anyone
have any ideas on
? As long as
Tcl is built with support for the load command,
I don't think it would be a problem. Of course,
you would not be able to load Tcl + Tcl Blend
into a JVM if it was not build as a shared library,
but that is fine.
Mo DeJong
Red Hat Inc
-aware.
David Gravereaux sent out an email to the TEA mailing
list about a mechanism that would allow TclBlend to
find the Tcl DLLs and load the stub table (when loading
blend from the JVM).
Sounds good. Could you repost that email to this list.
Better yet, a patch to implement Davids approach.
Mo
On Thu, 29 Jun 2000, Dr Wes Munsil wrote:
Mo DeJong wrote:
There is no "compile time" in Tcl, it is all dynamic, ...
Exactly my point. Consider these two code snippets, which I assume you agree are
correct uses
of newInstance():
B x = new C ();
ReflectObject.newInstan
Jacl and Tcl Blend for people to bang on.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subje
yone called getClass() everywhere
without realizing how it could hose things up, that would
be bad.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail
invalid entry,
...
I tested this under JDK 1.1.8 from Blackdown and Kaffe
and there was no problem with either of those JVMs
(I ran the test for several hours).
thanks
Mo DeJong
Red Hat Inc
ReflectCrash.zip
r own "lock and unlock" on top of
the existing reflection system. In fact, that is exactly
what the java::lock and java::unlock commands are for.
The only reason they were added was because of this
exact problem.
I think we need to change Tcl to support "loc
On Thu, 29 Jun 2000, Jeff Sturm wrote:
Mo DeJong wrote:
Here is another example:
import java.util.Hashtable;
public class Hashtable2 extends Hashtable
{
public static Hashtable get() {
return new Hashtable2();
}
public void NEVER_CALL() {
System.out.println
On Wed, 28 Jun 2000, Dr Wes Munsil wrote:
Mo DeJong wrote:
Objects do not have types, references to objects determine what behavior
the object will provide. In Tcl/Java you don't really have a reference
but you "reflect" an object as a type. You need to pass in the
java.
fix it Tcl would need to be extended so that it supported
another sort of internal rep that could not be disposed of.
I talked with Paul Duffin about this sort of thing at the
last Tcl conference. He is doing something similar called
"feather". It is an interesting area, but I have not had
m
is in the TclList class.
I guess this was done so that a Tcl List would not need to get converted
to a Java Vector if it was to be used from Java code. Are TclList internal
reps the only area where we have a problem? I think that is the case but
I am not sure.
Mo DeJong
Red Hat Inc
tcllist.png
not do that! You really need to know the type
of the object you are going to reflect. If you just call o.getClass()
it could be anything. I don't know if this is related to the problem
you are running into, but it is a really bad idea.
Mo DeJong
Red Hat Inc
TclObject(TclString rep, String s) {
internalRep = rep;
stringRep = s;
refCount = 0;
}
Seems like that might be the cause of some big problems.
I think this was something that was changed in Tcl sometime
after Tcl 8.0.
Mo DeJong
R
ually breaks a couple of other things in the
test suite so it is not going to be checked in, but
you can use it on your own tree. The "real" fix
is going to take some time to implement, and I
am not going to be able to get to it for at least
a month.
Mo DeJong
Red Hat Inc
I
a C pointer inside a Java
long. It then converts this back to a pointer that is uses to find
the actual object (yes it is scary and wrong, but JNI sucks so we
are stuck with it).
Also, that convert a pointer to a string and back again trick
would not work if you were using a GC for your C code.
Mo
d by Tcl. Of
course, this means we would need a thread enabled Tcl.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word
On Mon, 19 Jun 2000, Jeff Sturm wrote:
Mo DeJong wrote:
I think this one is along the same lines. The finalizer thread seems
to be called decrRefCount() which is calling FreeTclObject(). I
think we need a more general solution to the problem of the
finalizer thread walking
On Mon, 19 Jun 2000, Jeff Sturm wrote:
Mo DeJong wrote:
What is a "thin lock"? Did you mean spin lock? I don't see what is
wrong with a good old mutex, but putting one in means we would
need to require a thread safe version of Tcl. I don't really
like the "use the JV
o solve some other deadlocking
problems, but at least it loads without a SIGSEGV now :)
Mo Dejong
Red Hat Inc.
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
{
mInterp = interp;
}
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To uns
1 - 100 of 161 matches
Mail list logo
