tcljava-user — Ask questions and get help here

Re: [tcljava-user] Java Keyword - "this".

[D.J.Hagberg <dha...@mi...>]

Patrick,

I'm not sure if I'm permitted to reply to your message, based on the 
nasty notice at the bottom of your email but here goes --

Well, there is no straight equivalent, since the Jacl code isn't really 
a Java object.  You would need to pass in some /other/ Java object that 
implements the required interface -- in your case an instance of 
NotificationListener.

I don't believe that Jacl has the capabilities that some other JVM 
scripting languages (Rhino, Jython, and Groovy come to mind) for the 
script to implement a particular interface.  Perhaps I stand to be 
corrected?

You may be able to extend the interpreter to provide a facility like 
this using JDK 1.3+'s dynamic proxy support, unless someone's done this 
already.

			-=- D. J.

On Oct 27, 2005, at 9:22 PM, <PFi...@hb...> wrote:
> How do I code the java keyword "this" in JACL?
>
> JAVA Code.
>
> adminClient.addNotificationListener(nodeAgent, this, null, null);
>
> JACL Code.
>
> $AdminClientI addNotificationListener $nodeAgent this $nullI $nullI
>
> error in procedure java::call:
> "this" is not an object handle of class
> "javax.management.NotificationListener"
>
> I use java::null to get a handle to the null Java reference.  Is there
> something similar for the "this" keyword or a work around?
>
> Regards.
>
> Patrick.
>
> ===================================================
> HBF Health Funds Inc. a registered organisation under the National 
> Health Act
> HBF Insurance Pty Ltd ACN  009 268 277
> This email is a confidential communication intended only for the named 
> Addressee(s).
> If you are not that person any disclosure, copying, distribution or 
> use of this email
> or the information in it is prohibited. Please notify us immediately by
> telephone, (+61) 08 9265 6111 or return email and delete this email.
> The views in this email may be personal to the author and not those of 
> HBF.

[tcljava-user] Java Keyword - "this".

[<PFi...@hb...>]

How do I code the java keyword "this" in JACL?

JAVA Code.

adminClient.addNotificationListener(nodeAgent, this, null, null);

JACL Code.

$AdminClientI addNotificationListener $nodeAgent this $nullI $nullI

error in procedure java::call:
"this" is not an object handle of class 
"javax.management.NotificationListener"

I use java::null to get a handle to the null Java reference.  Is there 
something similar for the "this" keyword or a work around?

Regards.

Patrick.

===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s). 
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by 
telephone, (+61) 08 9265 6111 or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.

Re: [tcljava-user] java::cast issue.

[<PFi...@hb...>]

My java skills are a bit basic but I did try something like that.

Here is a line by line comparison.

JAVA:   Set s = adminClient.queryNames(queryName, null); 
JACL:   set s [ $AdminClientI queryNames $ObjectNameI $nullI ]

The "s" object needs to implement the iterator interface to loop through 
the array. 

JAVA:   nodeAgent = (ObjectName)s.iterator().next(); 
JACL:   set nodeAgent [ $mbeanList iterator next ]

The JACL statement does not cast to ObjectName as I want to keep this 
simple.  The JACL statement fails because the "s" object returned by the 
query does not implement the iterator interface where as the "s" object 
returned by the JAVA statement does. 

"can't find accessible method "iterator" with 1 argument(s) for class 
"java.util.
Set""

Of course now that I have read the javadoc more closely I can see that the 
problem occurs because an iterator object needs to be instanciated. 

The JACL code should look like this.

   set mBeanList [ $AdminClientI queryNames $ObjectNameI $nullI ]
   set iteratorI [ $mBeanList iterator ] 
   set yy [ $iteratorI next ]
   set askTedPortalMBeanI [ java::cast ObjectName $yy ] 

Thanks for your help.

Patrick.



===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s). 
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by 
telephone, (+61) 08 9265 6111 or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.

Re: [tcljava-user] java::cast issue.

[Mo D. <md...@un...>]

On Thu, 27 Oct 2005 17:04:24 +0800
<PFi...@hb...> wrote:

> I have an issue with java::cast.

>    nodeAgent = (ObjectName)s.iterator().next(); 

The cast to ObjectName is done with the result of the next() invocation.
The following example should make the order of operations clear.
Note that "(Two) obj1.foo()" and "(Two) (obj1.foo())" would give the
same result.

public class Ex {
    static class One {
        Two foo() { return new Two(); }
    }
    static class Two {}

    public static void main(String[] args) {
        One obj1 = new One();
        Two obj2 = (Two) obj1.foo();
        Two obj3 = (Two) (obj1.foo());
        System.out.println("OK");
    }
}


> This email is a confidential communication ...

Patrick, please read the mailing list terms of use. In particular, the part
on fictional contract claims. If you are unable to post without these
invalid disclaimers then please find another email address to post from.

http://tcljava.sourceforge.net/docs/website/mail.html

Mo DeJong

Re: [tcljava-user] java::cast issue.

[<PFi...@hb...>]

The problem seems to be that $beanList does not have an array signature. 

puts [ $beanList toString ] generates 
"[WebSphere:name=xxxxxxxxxxxxxxxxxxxxxxxxxx]".  I would assume that the 
"[]" indicate an array.

[$beanList length] generates "no accessible method "length" in class 
java.util.Set"


===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s). 
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by 
telephone, (+61) 08 9265 6111 or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.

[tcljava-user] java::cast issue.

[<PFi...@hb...>]

I have an issue with java::cast.

Java Code 
**************

"s" seems to be a hash returned by adminclient object. 
"s" is casted to type ObjectName then processed by Iterator. 

Set s = adminClient.queryNames(queryName, null); 
if (!s.isEmpty()) 
#################
   nodeAgent = (ObjectName)s.iterator().next(); 
################
else 
   System.out.println("Node agent MBean was not found");

Jacl Code 
**************

"beanList" is the hash. Contains one element.  See output below. 
Cannot cast.  MSG is "could not cast from java.util.HashSet to 
javax.management.ObjectName".


set beanList [ $AdminClientI queryNames $ObjectNameI $nullI ]
puts [ $beanList toString ]
puts "\n bean object dimensions are [ java::info dimensions $beanList ] "
puts "\n bean object properties are [ java::info properties $beanList ]"

set askTedPortalMBeanI [ [ java::cast ObjectName $beanList ] $beanList 
iterator next ] 
OutpuT 
**************


 beanList is :

[WebSphere:name=xxxxxxxxxxxxxxxxxxxxxxxxxx]

 bean object dimensions are 0

 bean object properties are empty
could not cast from java.util.HashSet to javax.management.ObjectName
    while executing
"java::cast ObjectName $beanList "






Regards.

PATRICK FINNEGAN.

===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s). 
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by 
telephone, (+61) 08 9265 6111 or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.

Re: [tcljava-user] Restrictions on java::import command

[Mo D. <md...@un...>]

On Thu, 20 Oct 2005 16:23:04 -0500
"Cargo, David" <Dav...@Xi...> wrote:

> The documentation on the java::import commands says:
> 
> The java::import command provides a means to specify Java class names in
> a
> shortened format. This functionality is the equivalent of the import
> statement
> in Java except that importing all classes from a package is not
> supported.
> 
> Is there any way to program around this?

I looked at that at the time I wrote that and there was no Java API to support
it. Anyway, it is not a good idea to being with, you should only import
the classes you actually use. Importing the classes adds entries to
a lookup table, so the total number of imports should be kept as small
as possible.

Mo DeJong

[tcljava-user] Restrictions on java::import command

[Cargo, D. <Dav...@Xi...>]

The documentation on the java::import commands says:

The java::import command provides a means to specify Java class names in
a
shortened format. This functionality is the equivalent of the import
statement
in Java except that importing all classes from a package is not
supported.

Is there any way to program around this?  The java::info command works
on
classes and objects; I don't see any obvious way to determine the
classes
in a package.

Thanks,

escargo 


---

David Cargo
Sr. Principal Engineer

Email: Dav...@Xi...
Office: 952 983 2372
Fax: 952 983 2320

Xiotech Corporation
6455 Flying Cloud Drive
Eden Prairie, MN 55344 

www.xiotech.com : www.xiotech.com/demo : Toll-Free 866 472 6764

RE: [tcljava-user] problems installing tclBlend on Linux

[Cargo, D. <Dav...@Xi...>]

We were unable to identify which of the clauses in the AC_JAVA_JNI_LIBS
function
was being hit.  We manually added the -ljsig and -ldbgmalloc to the
output of
configure, and things then built.  (There was one error out of > 1000
tests when
we ran "make test".)

When I ran jtclsh and did a "package require java" it reported back
1.3.2, so I'm
assuming that it built OK.  I'll be exercising it some more tomorrow.

Thanks for your help.

escargo




---

David Cargo
Sr. Principal Engineer

Email: Dav...@Xi...
Office: 952 983 2372
Fax: 952 983 2320

Xiotech Corporation
6455 Flying Cloud Drive
Eden Prairie, MN 55344 

www.xiotech.com : www.xiotech.com/demo : Toll-Free 866 472 6764


-----Original Message-----

From: tcl...@li...
[mailto:tcl...@li...] On Behalf Of Mo DeJong
Sent: Wednesday, October 19, 2005 1:28 PM
To: tcl...@li...
Subject: Re: [tcljava-user] problems installing tclBlend on Linux

<snip>

See my earlier note about the AC_JAVA_JNI_LIBS function in tcljava.m4
for more on how to fix this. There could be one of two fixes. Either add
-ljsig -ldbgmalloc to the compiler flags and see if that fixes it, or
this might be a runtime shared lib issue which means the runtime path
would need to include /usr/lib/IBMJava2-1-2.3/jre/bin. The runtime path
is not always the same as the compiler library search path.

cheers
Mo DeJong

RE: [tcljava-user] problems installing tclBlend on Linux

[Cargo, D. <Dav...@Xi...>]

I didn't see any example in tcljava.m4 that used -rpath; I think I see
where
in tcljava.m4 that it might go, but I'm blind about where it should go.

The config.log does assert that the jre/bin is part of the "runtime
library" path. 

I guess I'll first change line 846 of tcljava.m4 to include -ljsig and
-ldgbmalloc.

Thanks.

escargo




---

David Cargo
Sr. Principal Engineer

Email: Dav...@Xi...
Office: 952 983 2372
Fax: 952 983 2320

Xiotech Corporation
6455 Flying Cloud Drive
Eden Prairie, MN 55344 

www.xiotech.com : www.xiotech.com/demo : Toll-Free 866 472 6764


-----Original Message-----

From: tcl...@li...
[mailto:tcl...@li...] On Behalf Of Mo DeJong
Sent: Wednesday, October 19, 2005 1:28 PM
To: tcl...@li...
Subject: Re: [tcljava-user] problems installing tclBlend on Linux

On Wed, 19 Oct 2005 11:35:00 -0500
"Cargo, David" <Dav...@Xi...> wrote:

> Thanks to Mo and Patrick for their responses.
> 
> I was able to trace back the failure to at least a certain
circumstance.
> 
> config.log was proceeding normally until it got to the JNI test.
> Here there are two files that could not be found (libjsig.so and
> libdbgmalloc.so)
> even though they are in the /usr/lib/IBMJava2-1-2.3/jre/bin directory.
...
> -L/usr/lib/IBMJava2-1.4.2/jre/bin/classic -ljvm -lhpi >&5 
> /usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/bin
> /l
> d: warning: libjsig.so, needed by

See my earlier note about the AC_JAVA_JNI_LIBS function in tcljava.m4
for more on how to fix this. There could be one of two fixes. Either add
-ljsig -ldbgmalloc to the compiler flags and see if that fixes it, or
this might be a runtime shared lib issue which means the runtime path
would need to include /usr/lib/IBMJava2-1-2.3/jre/bin. The runtime path
is not always the same as the compiler library search path.

cheers
Mo DeJong


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads,
discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
tcljava-user mailing list
tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcljava-user

Re: [tcljava-user] problems installing tclBlend on Linux

[Mo D. <md...@un...>]

On Wed, 19 Oct 2005 11:35:00 -0500
"Cargo, David" <Dav...@Xi...> wrote:

> Thanks to Mo and Patrick for their responses.
> 
> I was able to trace back the failure to at least a certain circumstance.
> 
> config.log was proceeding normally until it got to the JNI test.
> Here there are two files that could not be found (libjsig.so and
> libdbgmalloc.so)
> even though they are in the /usr/lib/IBMJava2-1-2.3/jre/bin directory.
...
> -L/usr/lib/IBMJava2-1.4.2/jre/bin/classic -ljvm -lhpi >&5
> /usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/bin/l
> d: warning: libjsig.so, needed by

See my earlier note about the AC_JAVA_JNI_LIBS function in tcljava.m4 for
more on how to fix this. There could be one of two fixes. Either add
-ljsig -ldbgmalloc to the compiler flags and see if that fixes it, or this
might be a runtime shared lib issue which means the runtime path
would need to include /usr/lib/IBMJava2-1-2.3/jre/bin. The runtime
path is not always the same as the compiler library search path.

cheers
Mo DeJong

RE: [tcljava-user] problems installing tclBlend on Linux

[Cargo, D. <Dav...@Xi...>]

Thanks to Mo and Patrick for their responses.

I was able to trace back the failure to at least a certain circumstance.

config.log was proceeding normally until it got to the JNI test.
Here there are two files that could not be found (libjsig.so and
libdbgmalloc.so)
even though they are in the /usr/lib/IBMJava2-1-2.3/jre/bin directory.

I've included the failed section of the log, and then the cache
variables and
output variables.

(We did download the tcl/tk 8.4.11 sources and rebuild everything from
source.)

configure:4585: checking to see if we can link a JNI application
configure:4620: gcc -pipe -o conftest -g -O2
-I/usr/lib/IBMJava2-1.4.2/include   conftest.c  -lpthread
-L/usr/lib/IBMJava2-1.4.2/jre/bin -ljava
-L/usr/lib/IBMJava2-1.4.2/jre/bin/classic -ljvm -lhpi >&5
/usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/bin/l
d: warning: libjsig.so, needed by
/usr/lib/IBMJava2-1.4.2/jre/bin/libjava.so, not found (try using -rpath
or -rpath-link)
/usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/bin/l
d: warning: libdbgmalloc.so, needed by
/usr/lib/IBMJava2-1.4.2/jre/bin/libhpi.so, not found (try using -rpath
or -rpath-link)
/usr/lib/IBMJava2-1.4.2/jre/bin/libjava.so: undefined reference to
`jsig_primary_sigaction'
/usr/lib/IBMJava2-1.4.2/jre/bin/libjava.so: undefined reference to
`jsig_handler'
/usr/lib/IBMJava2-1.4.2/jre/bin/libhpi.so: undefined reference to
`dbgRealloc'
/usr/lib/IBMJava2-1.4.2/jre/bin/libhpi.so: undefined reference to
`dbgMalloc'
/usr/lib/IBMJava2-1.4.2/jre/bin/libhpi.so: undefined reference to
`dbgFree'
/usr/lib/IBMJava2-1.4.2/jre/bin/libhpi.so: undefined reference to
`dbgCalloc'
collect2: ld returned 1 exit status
configure:4623: $? = 1
configure: failed program was:
| #line 4601 "configure"
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
| 
|             #include <jni.h>
| 
| int
| main ()
| {
| JNI_GetCreatedJavaVMs(NULL,0,NULL);
|   ;
|   return 0;
| }
configure:4649: result: no
configure:4726: error: could not link file that includes jni.h
        Either the configure script does not know how to deal with
        this JVM configuration or the JVM install is broken or
corrupted.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_c_compiler_gnu=yes
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_exeext=
ac_cv_objext=o
ac_cv_path_DDD=/usr/bin/ddd
ac_cv_path_GDB=/usr/bin/gdb
ac_cv_path_JAR=/usr/lib/IBMJava2-1.4.2/bin/jar
ac_cv_path_JAVA=/usr/lib/IBMJava2-1.4.2/bin/java
ac_cv_path_JAVAH=/usr/lib/IBMJava2-1.4.2/bin/javah
ac_cv_path_JDB=/usr/lib/IBMJava2-1.4.2/bin/jdb
ac_cv_path_JIKES=
ac_cv_prog_ac_ct_CC='gcc -pipe'
ac_cv_prog_cc_g=yes
ac_cv_prog_cc_stdc=

## ----------------- ##
## Output variables. ##
## ----------------- ##

BUILD_DIR=''
BUILD_DIR_NATIVE=''
CC='gcc -pipe'
CFLAGS='-g -O2'
CPPFLAGS=''
DDD='/usr/bin/ddd'
DEFS=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EXEC_PREFIX_NATIVE=''
EXEEXT=''
GDB='/usr/bin/gdb'
JAR='/usr/lib/IBMJava2-1.4.2/bin/jar'
JAR_COMPRESS_FLAGS=''
JAR_EXTRACT_FLAGS=''
JAR_NOCOMPRESS_FLAGS=''
JAVA='/usr/lib/IBMJava2-1.4.2/bin/java'
JAVAC='/usr/lib/IBMJava2-1.4.2/bin/javac'
JAVAC_D_FLAG='-d'
JAVAC_FLAGS='-g'
JAVAH='/usr/lib/IBMJava2-1.4.2/bin/javah'
JAVA_CLASSPATH=''
JAVA_CLASSPATH_NATIVE=''
JAVA_FLAGS=''
JAVA_G='/usr/lib/IBMJava2-1.4.2/bin/java'
JAVA_G_FLAGS='-Xdebug
-Xrunjdwp:transport=dt_socket,address=8757,server=y,suspend=n
-Xbootclasspath/a:/usr/lib/IBMJava2-1.4.2/lib/tools.jar'
JAVA_INCLUDE_FLAGS=''
JAVA_LIB_FLAGS=''
JAVA_LIB_RUNTIME_PATH=''
JAVA_LIB_RUNTIME_PATH_NATIVE=''
JAVA_NATIVE=''
JDB='/usr/lib/IBMJava2-1.4.2/bin/jdb'
JDB_ATTACH_FLAGS='-attach 8757'
JIKES=''
LDFLAGS=''
LIBOBJS=''
LIBS=''
LTLIBOBJS=''
OBJEXT='o'
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_VERSION=''
PATH_SEPARATOR=':'
PREFIX_NATIVE=''
SHELL='/bin/sh'
SHLIB_CFLAGS='-fPIC'
SHLIB_LD='gcc -pipe -shared'
SHLIB_LD_LIBS='${LIBS}'
SHLIB_PREFIX='lib'
SHLIB_SUFFIX='.so'
SHLIB_VERSION=''
TCLBLEND_LD_BIND_NOW=''
TCLBLEND_LD_PRELOAD=''
TCLJAVA='tclblend'
TCLJAVA_DBGX=''
TCLJAVA_NODOT_VERSION='132'
TCLJAVA_VERSION='1.3.2'
TCLSH='/usr/local/bin/tclsh8.4'
TCLSH_NATIVE=''
TCL_BIN_DIR='/usr/local/src/tcl8.4.11/unix'
TCL_BIN_TCLSH=''
TCL_BUILD_LIB_SPEC='-L/usr/local/src/tcl8.4.11/unix -ltcl8.4${TCL_DBGX}'
TCL_CFLAGS='-O2'
TCL_DBGX=''
TCL_DEFS=' -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1
-D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1
-DHAVE_PTHREAD_ATFORK=1 -DHAVE_READDIR_R=1 -DHAVE_THREE_ARG_READDIR_R=1
-DPEEK_XCLOSEIM=1 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1
-DHAVE_STRTOL=1 -DHAVE_STRTOLL=1 -DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1
-DHAVE_WAITPID=1 -DHAVE_LIMITS_H=1 -DHAVE_UNISTD_H=1
-DHAVE_SYS_PARAM_H=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1
-DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1
-DHAVE_LOCALTIME_R=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1
-DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1 -DHAVE_SIGNED_CHAR=1
-DHAVE_LANGINFO=1 -DHAVE_SYS_IOCTL_H=1 '
TCL_INSTALL_LIB_DIR='/usr/local/lib'
TCL_LD_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}'
TCL_LIBS='-ldl  -lpthread -lieee -lm'
TCL_SRC_DIR='/usr/local/src/tcl8.4.11'
TCL_VERSION='8.4'
THREAD_BIN_DIR='/usr/local/src/thread2.6.2'
THREAD_BIN_DIR_NATIVE=''
TOP_DIR=''
TOP_DIR_NATIVE=''
WISH='/usr/local/bin/wish8.4'
ac_ct_CC='gcc -pipe'
bindir='${exec_prefix}/bin'
build_alias=''
datadir='${prefix}/share'
exec_prefix='NONE'
host_alias=''
includedir='${prefix}/include'
infodir='${prefix}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
oldincludedir='/usr/include'
prefix='NONE'
program_transform_name='s,x,x,'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_BUGREPORT ""
#define PACKAGE_NAME ""
#define PACKAGE_STRING ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""

configure: exit 1 




---

David Cargo
Sr. Principal Engineer

Email: Dav...@Xi...
Office: 952 983 2372
Fax: 952 983 2320

Xiotech Corporation
6455 Flying Cloud Drive
Eden Prairie, MN 55344 

www.xiotech.com : www.xiotech.com/demo : Toll-Free 866 472 6764


-----Original Message-----

From: tcl...@li...
[mailto:tcl...@li...] On Behalf Of Mo DeJong
Sent: Tuesday, October 18, 2005 3:42 PM
To: tcl...@li...
Subject: Re: [tcljava-user] problems installing tclBlend on Linux

On Tue, 18 Oct 2005 15:04:23 -0500
"Cargo, David" <Dav...@Xi...> wrote:

> I'm trying to install tclBlend (and therefore tcl and the thread
> package)
> on the following Linux system:
> 
> Because SUSE had Tcl 8.4.6 installed, I went with Tcl/Tk 8.4.6.  The 
> java JDK used is the IBMJava2-1.4.2 package from SUSE's repository.

Hello David

Please use Tcl/Tk 8.4.11, 8.4.6 is very old by now. It does not matter
what version of Tcl the system comes with since Tcl Blend depends on Tcl
being compiled with thread support anyway.

See:

http://wiki.tcl.tk/9993


> Using the following JNI include flags -I/usr/lib/java/include checking

> to see if jni.h can be included... yes Using the following JNI library

> flags -lpthread -L/usr/lib/java/jre/bin -ljava 
> -L/usr/lib/java/jre/bin/classic -ljvm -lhpi Using the following 
> runtime library path 
> /usr/lib/java/jre/bin:/usr/lib/java/jre/bin/classic
> checking to see if we can link a JNI application... no
> configure: error: could not link file that includes jni.h
>         Either the configure script does not know how to deal with
>         this JVM configuration or the JVM install is broken or

The Tcl Blend configure script does not know how to find the libs it
needs for your JVM layout. See the file tcljava.m4 and the
AC_JAVA_JNI_LIBS function. I know it looks scary, but I need you to take
a look at the directory layout of JVM files on your system, and add some
checks that look for the specific layout to the AC_JAVA_JNI_LIBS method.
If you need some help, please post the results of 'find .' run from the
root of the JDK dir and I will help you get started. Also note that you
will need to run the autogen.sh script after changing the tcljava.m4 to
get a new configure script.

cheers
Mo DeJong

Re: [tcljava-user] problems installing tclBlend on Linux

[<PFi...@hb...>]

For what it's worth I built TclBlend successfully on Windows with IBM JDK 
1.4.2.

P:\>C:\tclBlend\IBMJDK142\bin\java -fullversion
java full version "J2RE 1.4.2 IBM Windows 32 build cn1420-20040626"

The Tcl components used in the build were: 

P:\>dir C:\msys\home\PYF\build

17/08/2005  12:21 PM    <DIR>          tcl8.4.11
17/08/2005  11:50 AM    <DIR>          tclBlend1.3.2
01/08/2005  02:29 PM    <DIR>          thread2.6.2
01/08/2005  07:21 PM    <DIR>          tk8.4.11

Regards.


PATRICK FINNEGAN.
IBM WebSphere Consultant.
HBF Web Master
LDAP Administrator.
PH: +61 (0)8 9265 6569
FX: +61 (0)8 9265 6380
MB: +61 (0)402 232619 



Mo DeJong <md...@un...> 
Sent by: tcl...@li...
19/10/2005 04:42 AM
Please respond to
tcl...@li...


To
tcl...@li...
cc

Subject
Re: [tcljava-user] problems installing tclBlend on Linux






On Tue, 18 Oct 2005 15:04:23 -0500
"Cargo, David" <Dav...@Xi...> wrote:

> I'm trying to install tclBlend (and therefore tcl and the thread
> package)
> on the following Linux system:
> 
> Because SUSE had Tcl 8.4.6 installed, I went with Tcl/Tk 8.4.6.  The
> java JDK
> used is the IBMJava2-1.4.2 package from SUSE's repository.

Hello David

Please use Tcl/Tk 8.4.11, 8.4.6 is very old by now. It does not matter
what version of Tcl the system comes with since Tcl Blend depends
on Tcl being compiled with thread support anyway.

See:

http://wiki.tcl.tk/9993


> Using the following JNI include flags -I/usr/lib/java/include
> checking to see if jni.h can be included... yes
> Using the following JNI library flags -lpthread -L/usr/lib/java/jre/bin
> -ljava -L/usr/lib/java/jre/bin/classic -ljvm -lhpi
> Using the following runtime library path
> /usr/lib/java/jre/bin:/usr/lib/java/jre/bin/classic
> checking to see if we can link a JNI application... no
> configure: error: could not link file that includes jni.h
>         Either the configure script does not know how to deal with
>         this JVM configuration or the JVM install is broken or

The Tcl Blend configure script does not know how to find the libs it needs
for your JVM layout. See the file tcljava.m4 and the AC_JAVA_JNI_LIBS
function. I know it looks scary, but I need you to take a look at the 
directory
layout of JVM files on your system, and add some checks that look
for the specific layout to the AC_JAVA_JNI_LIBS method. If you need some
help, please post the results of 'find .' run from the root of the JDK
dir and I will help you get started. Also note that you will need to run 
the
autogen.sh script after changing the tcljava.m4 to get a new configure 
script.

cheers
Mo DeJong


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
tcljava-user mailing list
tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcljava-user



===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s). 
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by 
telephone, (+61) 08 9265 6111 or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.

Re: [tcljava-user] problems installing tclBlend on Linux

[Mo D. <md...@un...>]

On Tue, 18 Oct 2005 15:04:23 -0500
"Cargo, David" <Dav...@Xi...> wrote:

> I'm trying to install tclBlend (and therefore tcl and the thread
> package)
> on the following Linux system:
> 
> Because SUSE had Tcl 8.4.6 installed, I went with Tcl/Tk 8.4.6.  The
> java JDK
> used is the IBMJava2-1.4.2 package from SUSE's repository.

Hello David

Please use Tcl/Tk 8.4.11, 8.4.6 is very old by now. It does not matter
what version of Tcl the system comes with since Tcl Blend depends
on Tcl being compiled with thread support anyway.

See:

http://wiki.tcl.tk/9993


> Using the following JNI include flags -I/usr/lib/java/include
> checking to see if jni.h can be included... yes
> Using the following JNI library flags -lpthread -L/usr/lib/java/jre/bin
> -ljava -L/usr/lib/java/jre/bin/classic -ljvm -lhpi
> Using the following runtime library path
> /usr/lib/java/jre/bin:/usr/lib/java/jre/bin/classic
> checking to see if we can link a JNI application... no
> configure: error: could not link file that includes jni.h
>         Either the configure script does not know how to deal with
>         this JVM configuration or the JVM install is broken or

The Tcl Blend configure script does not know how to find the libs it needs
for your JVM layout. See the file tcljava.m4 and the AC_JAVA_JNI_LIBS
function. I know it looks scary, but I need you to take a look at the directory
layout of JVM files on your system, and add some checks that look
for the specific layout to the AC_JAVA_JNI_LIBS method. If you need some
help, please post the results of 'find .' run from the root of the JDK
dir and I will help you get started. Also note that you will need to run the
autogen.sh script after changing the tcljava.m4 to get a new configure script.

cheers
Mo DeJong

[tcljava-user] problems installing tclBlend on Linux

[Cargo, D. <Dav...@Xi...>]

I'm trying to install tclBlend (and therefore tcl and the thread
package)
on the following Linux system:

SUSE Linux Enterprise Server 9 SP2 OS. 
Dual 2.8 GHz Xeon processors.

Because SUSE had Tcl 8.4.6 installed, I went with Tcl/Tk 8.4.6.  The
java JDK
used is the IBMJava2-1.4.2 package from SUSE's repository.

(With this JDK, jacl built OK, but now I see that if I "make test" it
gets to
tcl/stack.test and then errors out with "make: *** [test_jacl.exec]
Error 139".)

The tcl built OK and passed its tests (with threads enabled).

The thread package built OK and passed its tests.

[/usr/local/src/tclBlend1.3.2]# ./configure
--with-tcl=/usr/local/src/tcl8.4.6
--with-thread=/usr/local/src/thread2.6.2
srcdir is /usr/local/src/tclBlend1.3.2
checking for Tcl build in /usr/local/src/tcl8.4.6
checking for Thread build in /usr/local/src/thread2.6.2
Tcl executable /usr/local/src/tcl8.4.6/unix/tclsh works
Tcl was compiled with Thread support
checking for jikes... no
checking for javac... /usr/lib/java/bin/javac
checking for zip or jar files to include on CLASSPATH...
/usr/lib/java/jre/lib/core.jar
checking to see if the java compiler works... yes
checking to see if the java compiler accepts forward slashes... yes
Java found in /usr/lib/java
checking type of jvm... jdk
checking java API version... 1.3
checking for java... /usr/lib/java/bin/java
checking for java_g... no
checking for javah... /usr/lib/java/bin/javah
checking for jar... /usr/lib/java/bin/jar
checking for jdb... /usr/lib/java/bin/jdb
checking for ddd... /usr/bin/ddd
checking for gdb... /usr/bin/gdb
checking for gcc... gcc -pipe
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc -pipe accepts -g... yes
checking for gcc -pipe option to accept ANSI C... none needed
Using the following JNI include flags -I/usr/lib/java/include
checking to see if jni.h can be included... yes
Using the following JNI library flags -lpthread -L/usr/lib/java/jre/bin
-ljava -L/usr/lib/java/jre/bin/classic -ljvm -lhpi
Using the following runtime library path
/usr/lib/java/jre/bin:/usr/lib/java/jre/bin/classic
checking to see if we can link a JNI application... no
configure: error: could not link file that includes jni.h
        Either the configure script does not know how to deal with
        this JVM configuration or the JVM install is broken or
corrupted.

Would using the standard Sun (which suppose means Blackdown) JDK work
better?  Is this
a known problem?  (Not that I could tell from the archives.)  Are there
specific things
I can test myself to get better identification of the problem?

Thanks,

escargo 


---

David Cargo
Sr. Principal Engineer

Email: Dav...@Xi...
Office: 952 983 2372
Fax: 952 983 2320

Xiotech Corporation
6455 Flying Cloud Drive
Eden Prairie, MN 55344 

www.xiotech.com : www.xiotech.com/demo : Toll-Free 866 472 6764

Re: [tcljava-user] Windows jwish - Clarification needed.

[Mo D. <md...@un...>]

On Mon, 17 Oct 2005 19:16:44 +0800
<PFi...@hb...> wrote:

> The jwish file generated by the compile instructions at 
> "http://wiki.tcl.tk/9993" and the doco infer that "jwish" on Windows must 
> be run from the msys shell.  Is there any reason for this given that 
> "jtclsh" runs quite happily from the Windows command shell? 

When you  run "jtclsh" from a cmd.exe shell, it runs jtclsh.bat. The jwish
script runs jwish.sh which is a symlink to jtclsh, not jtclsh.bat. You could
always create a jwish.bat script by copying the jtclsh.bat script, but this
is not done automatically.

cheers
Mo DeJong

[tcljava-user] Windows jwish - Clarification needed.

[<PFi...@hb...>]

The jwish file generated by the compile instructions at 
"http://wiki.tcl.tk/9993" and the doco infer that "jwish" on Windows must 
be run from the msys shell.  Is there any reason for this given that 
"jtclsh" runs quite happily from the Windows command shell? 

Regards.


PATRICK FINNEGAN.
IBM WebSphere Consultant.
HBF Web Master
LDAP Administrator.
PH: +61 (0)8 9265 6569
FX: +61 (0)8 9265 6380
MB: +61 (0)402 232619 
===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s). 
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by 
telephone, (+61) 08 9265 6111 or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.

[tcljava-user] TclBlend - Examples.

[<PFi...@hb...>]

Two example scripts available from Active State Tcl cookbook.

http://aspn.activestate.com/ASPN/Cookbook/Tcl?kwd=TclBlend

1.      TclBlend with Type 4 Java jdbc drivers.

2.      TclBlend with Java Messaging Service Specification.

Regards.


PATRICK FINNEGAN.
IBM WebSphere Consultant.
HBF Web Master
LDAP Administrator.
PH: +61 (0)8 9265 6569
FX: +61 (0)8 9265 6380
MB: +61 (0)402 232619 
===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s). 
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by 
telephone, (+61) 08 9265 6111 or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.

Re: [tcljava-user] Seems to work on AMD64 Linux

[Mo D. <md...@un...>]

On Fri, 14 Oct 2005 15:41:56 -0600
Scott Serr <ss...@am...> wrote:

> Oddly enough I just figured out what is in the native_threads.  It is 
> libhpi.so.  (I forgot that) I removed the "-lhpi" and it compiles and 
> apparently runs properly.  So I guess we don't need hpi/native_threads?  
> Maybe it's a legacy thing for a 1.3 or 1.4 x86 that we don't need to 
> worry about in this instance.

Well, the sure fire way to test this is to run "make test" from the Tcl Blend
build dir. That will test normal loading and it will also test loading both
Tcl Blend and Tcl into a JVM started from the java.exe process. In some
cases, it may work when loaded into tclsh but not when both Tcl and TclBlend
are loaded into Java. Just let me know if you run into any problems.

cheers
Mo DeJong

Re: [tcljava-user] Seems to work on AMD64 Linux

[Scott S. <ss...@am...>]

Mo DeJong wrote:

>On Fri, 14 Oct 2005 07:51:03 -0600
>Scott Serr <ss...@am...> wrote:
>
>  
>
>>You are right, I missed that "$machine" reference.  It should be "amd64" 
>>or it should be taken out. Here is a question that might help resolve 
>>which way to go...  I run tclsh and setup the environment manually much 
>>like jclsh does -- all in 32bit Linux.  I noticed that I could leave out 
>>2 or 3 directories from the LD_LIBRARY_PATH and still have a "working" 
>>(as far as I know) TclBlend.  One directory I could leave out for 
>>32bit/x86 Linux (with Sun JDK 1.5 atleast) was "native_threads".  Is 
>>this going to bite me later?  or is "native_threads" not necessary?
>>    
>>
>
>I took it out and checked into the CVS again. You would know if you
>needed the dir, since Tcl Blend would not load if it was missing.
>  
>
Oddly enough I just figured out what is in the native_threads.  It is 
libhpi.so.  (I forgot that) I removed the "-lhpi" and it compiles and 
apparently runs properly.  So I guess we don't need hpi/native_threads?  
Maybe it's a legacy thing for a 1.3 or 1.4 x86 that we don't need to 
worry about in this instance.

>>Trying to login to CVS...  did this from 2 different hosts/networks and 
>>still no luck, I'll try later.
>>    
>>
>
>Yeah, SF CVS can be a bit flaky sometimes.
>  
>
Thanks...  I'll try again.

Re: [tcljava-user] Seems to work on AMD64 Linux

[Mo D. <md...@un...>]

On Fri, 14 Oct 2005 07:51:03 -0600
Scott Serr <ss...@am...> wrote:

> You are right, I missed that "$machine" reference.  It should be "amd64" 
> or it should be taken out. Here is a question that might help resolve 
> which way to go...  I run tclsh and setup the environment manually much 
> like jclsh does -- all in 32bit Linux.  I noticed that I could leave out 
> 2 or 3 directories from the LD_LIBRARY_PATH and still have a "working" 
> (as far as I know) TclBlend.  One directory I could leave out for 
> 32bit/x86 Linux (with Sun JDK 1.5 atleast) was "native_threads".  Is 
> this going to bite me later?  or is "native_threads" not necessary?

I took it out and checked into the CVS again. You would know if you
needed the dir, since Tcl Blend would not load if it was missing.

> Trying to login to CVS...  did this from 2 different hosts/networks and 
> still no luck, I'll try later.

Yeah, SF CVS can be a bit flaky sometimes.

cheers
Mo DeJong

Re: [tcljava-user] Seems to work on AMD64 Linux

[Scott S. <ss...@am...>]

Mo DeJong wrote:

>On Thu, 13 Oct 2005 21:48:53 -0600
>Scott Serr <ss...@am...> wrote:
>
>Hello Scott
>
>  
>
>>After fiddling with tcljava.m4 I was able to get tclBlend to compile.  
>>It's probably not as good as it could be, but it works and jtclsh gets 
>>the right env too.  (note that uname -m and $machine are "x86_64" not 
>>"amd64" thats why the hard coded match)
>>    
>>
>
>Nice work. It is really tricky keeping Tcl Blend working with all the
>wacky JVM configurations out there.
>  
>
Thanks, I had no idea how wacky before visiting this file.

>  
>
>>I've never done m4 and I don't know much about autoconf, so hopefully 
>>this work (sweat) helps someone or can be commited to CVS.
>>    
>>
>
>I just checked your patch into CVS. Could you check out the CVS version
>and double check that it works? One thing I noticed that I wanted to
>ask you about was the $JAVA/jre/lib/$machine/native_threads part.
>Does that actually resolve a library at link time or runtime? I was not
>sure from your patch if that was actually needed. If that dir is not actually
>used to resolve anything, then it would be better to remove it.
>
>  
>
You are right, I missed that "$machine" reference.  It should be "amd64" 
or it should be taken out.  Here is a question that might help resolve 
which way to go...  I run tclsh and setup the environment manually much 
like jclsh does -- all in 32bit Linux.  I noticed that I could leave out 
2 or 3 directories from the LD_LIBRARY_PATH and still have a "working" 
(as far as I know) TclBlend.  One directory I could leave out for 
32bit/x86 Linux (with Sun JDK 1.5 atleast) was "native_threads".  Is 
this going to bite me later?  or is "native_threads" not necessary?

Trying to login to CVS...  did this from 2 different hosts/networks and 
still no luck, I'll try later.
# cvs -d:pserver:ano...@cv...:/cvsroot/tcljava login
(Logging in to ano...@cv...)
CVS password:
cvs login: authorization failed: server cvs.sourceforge.net rejected 
access to /cvsroot/tcljava for user anonymous

Thanks,
Scott

>cheers
>Mo DeJong
>
>  
>

Re: [tcljava-user] Seems to work on AMD64 Linux

[Mo D. <md...@un...>]

On Thu, 13 Oct 2005 21:48:53 -0600
Scott Serr <ss...@am...> wrote:

Hello Scott

> After fiddling with tcljava.m4 I was able to get tclBlend to compile.  
> It's probably not as good as it could be, but it works and jtclsh gets 
> the right env too.  (note that uname -m and $machine are "x86_64" not 
> "amd64" thats why the hard coded match)

Nice work. It is really tricky keeping Tcl Blend working with all the
wacky JVM configurations out there.

> I've never done m4 and I don't know much about autoconf, so hopefully 
> this work (sweat) helps someone or can be commited to CVS.

I just checked your patch into CVS. Could you check out the CVS version
and double check that it works? One thing I noticed that I wanted to
ask you about was the $JAVA/jre/lib/$machine/native_threads part.
Does that actually resolve a library at link time or runtime? I was not
sure from your patch if that was actually needed. If that dir is not actually
used to resolve anything, then it would be better to remove it.

cheers
Mo DeJong

Re: [tcljava-user] Error "make install" Tclblend 1.3.2

[Mo D. <md...@un...>]

On Mon, 10 Oct 2005 12:10:55 +0800
"Adrian Tan" <ah...@te...> wrote:

Hi Adrian

> Exception in thread "main" java.lang.NullPointerexception: Invalid interpreter.
> 
>             at tcl.land.Interp.getCommand(Native Method)
> 
>             at tcl.land.BlendExtension.init(BlendExtension.java:39)

Humm, this is very odd. The interp pointer being passed via JNI seems to be NULL
somehow. I don't see how that could happen. I looked back at the mailing list
archive and the only other person to report a problem like this was also running
Fedora, so that makes me think this problem may have something to do with the
Java impl on that platform. First off, could you run the Tcl regression tests?
In the directory where you build Tcl, run "make test" and see if that passes the
tests.

If everything looks ok from the Tcl side, then could you try the attached patch?
Just apply it from the root of your Tcl Blend install and then rebuild? I don't see
how these extra asserts could be triggered, it is just an extra sanity check. If you
could also add -DTCLBLEND_DEBUG to the CFLAGS def in the generated Makefile
and then run `make shell` along with "package require java" in the Tcl shell, that
would really be helpful. You can just post the output written to the shell here.

thanks
Mo DeJong

[tcljava-user] Seems to work on AMD64 Linux

[Scott S. <ss...@am...>]

After fiddling with tcljava.m4 I was able to get tclBlend to compile.  
It's probably not as good as it could be, but it works and jtclsh gets 
the right env too.  (note that uname -m and $machine are "x86_64" not 
"amd64" thats why the hard coded match)

I've never done m4 and I don't know much about autoconf, so hopefully 
this work (sweat) helps someone or can be commited to CVS.

Thanks for all the work that goes into tclBlend,
-Scott

--------------------------

diff -Naur tclBlend1.3.2-old/tcljava.m4 tclBlend1.3.2-new/tcljava.m4
--- tclBlend1.3.2-old/tcljava.m4        2005-07-16 19:52:04.000000000 -0600
+++ tclBlend1.3.2-new/tcljava.m4        2005-10-13 21:41:11.000000000 -0600
@@ -924,6 +924,25 @@
             fi
         fi

+       # Sun JDK 1.5 for AMD64 Linux
+
+        F=jre/lib/amd64/libjava.so
+        if test "x$ac_java_jvm_jni_lib_flags" = "x" ; then
+            AC_MSG_LOG([Looking for $ac_java_jvm_dir/$F], 1)
+            if test -f $ac_java_jvm_dir/$F ; then
+                AC_MSG_LOG([Found $ac_java_jvm_dir/$F], 1)
+                D=`dirname $ac_java_jvm_dir/$F`
+                ac_java_jvm_jni_lib_runtime_path=$D
+                ac_java_jvm_jni_lib_flags="-L$D -ljava -lverify"
+               D=$ac_java_jvm_dir/jre/lib/amd64/server
+                
ac_java_jvm_jni_lib_runtime_path="${ac_java_jvm_jni_lib_runtime_path}:$D"
+                ac_java_jvm_jni_lib_flags="$ac_java_jvm_jni_lib_flags 
-L$D -ljvm"
+                D=$ac_java_jvm_dir/jre/lib/$machine/native_threads
+                
ac_java_jvm_jni_lib_runtime_path="${ac_java_jvm_jni_lib_runtime_path}:$D"
+                ac_java_jvm_jni_lib_flags="$ac_java_jvm_jni_lib_flags -L$D"
+            fi
+        fi
+
         # Blackdown JDK 1.1 for Linux (this one can get a little wacky)

         F=README.linux

----------------------------