Native Threads Help

1999-10-17 Thread Aaron Mulder

I just installed the native threads add-on to the 1.1.7 JRE and
whenever I try to use it (jre -native test) I get the following result:

Cannot open /proc/02891 for GCCould not create Java VM

Where the proc number changes every time...  I'm using Red Hat
6.1 on a 2-processor system.  Any thoughts would be appreciated.

Thanks,
Aaron


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Native Threads Help

1999-10-17 Thread Aaron Mulder

Is there any workaround?  I installed Oracle for Linux, and all
it's tools run via java -native, and there are *ever so many* scripts to
edit to change that!  ;)

Thanks,
Aaron

P.S. to Nathan: I have a /proc filesystem and the kernel is compiled from
the Red Hat 2.2.12 source with some of the shared memory size tweaks for
Oracle.

On 17 Oct 1999, Juergen Kreileder wrote:
> >>>>> Aaron Mulder writes:
> 
> Aaron> I just installed the native threads add-on to the 1.1.7 JRE
> Aaron> and whenever I try to use it (jre -native test) I get the
> Aaron> following result:
> 
> Aaron> Cannot open /proc/02891 for GCCould not create Java VM
> 
> Aaron> Where the proc number changes every time...  I'm using Red
> Aaron> Hat6.1 on a 2-processor system.  Any thoughts would be
> Aaron> appreciated.
> 
> It's a bug.  Fixed in the next release.
> 
> 
> Juergen
> 
> -- 
> Juergen Kreileder, Blackdown Java-Linux Porting Team
> http://www.blackdown.org/java-linux.html
> 



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



RE: JNI link to disk space

1999-10-20 Thread Aaron Mulder

Sure, but the Java white papers keep mentioning things like
"platform independent"...  I figure they must have *some* reason for it...

Aaron

On Wed, 20 Oct 1999, Burkhart,Kelly wrote:
> Why is it an ugly solution?  Unix apps do this sort of thing frequently.  It
> works fine.
> 
> > -Original Message-
> > I'm working on an installer that also needs to find out this 
> > information.
> > IBM Alphaworks has an Install Toolkit for Java that includes 
> > some classes
> > for doing this sort of thing.  For UNIX/Linux they just call 
> > df and parse
> > the output.  Sure, it's an ugly solution, but if it works and 
> > saves you
> > from writing some irritating parsing code...


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: CORBA advice

1999-10-31 Thread Aaron Mulder

I've used Orbacus, which may not be the most feature-complete, but
is all Java and works great on Linux.

Aaron

On Sun, 31 Oct 1999, Paul Gearon wrote:
> Hi,
> I've been mostly using C++ bindings for CORBA until now, but I'd like to
> start writing in Java.  Does anyone know a reasonable ORB for use with
> Linux?
> 
> TIA
> 
> Regards,
> Paul
> 
> Paul Gearon
> [EMAIL PROTECTED]
> 
> Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum
> immane
> mittam.
> (Translation from latin: "I have a catapult. Give me all the money, or I
> will
> fling an enormous rock at your head.")
> 
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: How do I create a 1-bit depth graphics in memory?

1999-11-02 Thread Aaron Mulder

I've run into this myself, and it seemed like the ColorModel class
assumes that you'll use either 1 byte or 1 int for each pixel.  So it
seemed like the best you could do was switch to 8-bit indexed color, which
is at least a 4x improvement.  If there is in fact a way to use a 1-bit
color model, I'd love to hear it!

Aaron

On Tue, 2 Nov 1999, Eric Chao wrote:
> Hi, I am currently trying to create a 1-bit depth graphics in memory.  I
> do not need color capabilities, just black-and-white. I am using a
> buffer made up of integers but it is a waste of memory when I can use
> 1-bit for a pixel instead of 32-bits.  What is the best way to do that?
> I need to switch to the more efficient way since Java complains
> OutOfMemory exception on large images
> 
> Eric Chao
> [EMAIL PROTECTED]
> Merlin Software Technologies Inc.
> 
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Oracle 8i & JDK 117v3

1999-11-11 Thread Aaron Mulder

Sorry for the somewhat off-topic post, but...  I need the help!

Anyone had success installing Oracle 8i on Linux?  I'm fighting
some problems with the configuration tools, which are all Java-based.

Thanks,
Aaron


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Oracle 8i & JDK 117v3

1999-11-12 Thread Aaron Mulder

On Fri, 12 Nov 1999, Ugo Cei wrote:
> I don't think this is off-topic at all.

Well, with that encouragement...

I've got a fresh install of Red Hat 6.1 on a P2-300 w/ 160MB and
JRE (actually we used the JRE for the install, not the JDK) 1.1.7v3.  The
big box is waiting for us to get the procedure straight.
The first problem was that the install program died complaining
that it couldn't create the virtual machine.  Apparently a script runs a
program that runs a script that starts a Java program, and the first
program died (is this the java -native problem?).  So we were able to
continue by doing what the first script did and running the second script
by hand.
Then, dbassist failed to launch from the install routine with the
error "not enough arguments".  When we tried to run it, it simply died,
which we traced to the fact that all the tools use java -native which does
nothing if native threads aren't installed (why not default to green?).
With suitable editing to .java_wrapper and jre, we got it to run using
green threads.
So we configured the instance with dbassist, generated shell
scripts to build the instance, and ran them.  We confirmed that we could
connect using the strangely named svrmgrl (Linux?) and "connect internal".

HOWEVER, we are unable to configure Net8.  The tools like
"netasst" and others (I've forgetten the others we tried) die with an
"Unable to load library" error.  The library in question (libnjni8.so) is
distributed by Oracle (see $ORACLE_HOME/lib), but with size 0 (both the
installed version and the version in the JAR on the CD).  The directory is
in our LD_LIBRARY_PATH, so I suspect it's just the "size 0" issue.
This means that we can't connect to the instance other than
through "connect internal", which is pretty useless.  We took a swing at
configuring a listener.ora by hand, but can't get past an error about "no
valid addresses specified"...

So my question is, what's going on?  Can I guess from the name
that the library in question relates to JNI for Native threads
(lib*njni*)?  If so, should we have a Blackdown version of this library
loaded before an Oracle version?  Or is this otherwise related to our
inability to run with native threads?

And on a related note, it would sure be nice to have a version of
the JDK with native threads that works with the glibc distributed with Red
Hat 6.1 (do I remember right 2.1.2?).  I won't ask when it's coming, I'll
just say that it would sure be nice.

Aaron


> I did it just yesterday, but I downloaded and installed JRE 1.1.6v5 as
> suggested by Oracle in its installation instructions. The only problem I
> had was with a message form dbassist telling me I had no support for
> national languages. I Ignored it and it created the database. Since then
> I just had the time to test that the instance is up and running.
> >  
> > Anyone had success installing Oracle 8i on Linux?  I'm fighting
> > some problems with the configuration tools, which are all Java-based.
> 
> This is on a RH 6.0 system with 256MB RAM + 256MB of swap.
> 
>   Ugo
> 
> -- 
> Ugo Cei - [EMAIL PROTECTED]
> Fuori Orario Srl - Galleria Manzoni 15, 27100 Pavia - Italy
> Tel: +39.382.22651, Fax: +39.382.539467
> 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]