jython-dev — Discussion of developing and enhancing Jython itself(!) (not how to use Jython)

[Jython-dev] Updated docs.

[<bc...@wo...>]

Hi,

I have updated the docs for jython and made them available at:

   http://jython.sourceforge.net/docs/index.html

The changes are:

- JPython changed to Jython.
- The 100% java certification removed.
- FAQ entries that tries to describe the jython/jpython situation.
- Technical correct description of registry properties.
- Removed description of proxycache and manual proxymaker.

This is temporary work-in-progress and some section are still missing,
but please give it a lookover and report your findings of mispellings,
bad grammar and techical mistakes.


We also need some new graphics. All images should be useable from java,
which mean .gif or .jpg.

- The top left image on the webpages above is 152 x 50 pixels.
- The image used by the installer is 78 x 399 pixels

Suggestions and submissions are welcome.

regards,
finn

Re: [Jython-dev] Another installer test.

[<bc...@wo...>]

[Adam Burke]

>Worked fine under
>
>Windows NT SP6 with
>Sun SDK2, JDK 1.2.2
>
>-o worked fine.  
>
>Under IBM jdk1.1.8 jythonc failed.  Does jython require Java 2?  (Personally
>it doesn't bother me if it does.)  It disturbs me that I did not pick this
>up on an earlier test.
>
>
>E:\tempinstall\jython-2.0pa0>jythonc b.py
>...
>1  .\org\python\core\Py.java:1509: Method getParentFile() not found in class.java.io.File.
>        file.getParentFile().mkdirs();
>                          ^

Thanks for the bugreport. I'll fix this because jython should certainly
be able to run on jdk1.1 compatible JVM's.

regards,
finn

RE: [Jython-dev] Another installer test.

[Adam B. <ada...@gb...>]

Worked fine under

Windows NT SP6 with
Sun SDK2, JDK 1.2.2

-o worked fine.  

Under IBM jdk1.1.8 jythonc failed.  Does jython require Java 2?  (Personally
it doesn't bother me if it does.)  It disturbs me that I did not pick this
up on an earlier test.


E:\tempinstall\jython-2.0pa0>jythonc b.py
processing b

Required packages:

Creating adapters:

Creating .java files:
  b module

Compiling .java to .class...
Compiling with args: ['c:\\jdk1.1.8\\bin\\..\\bin\\javac', '-classpath',
'e:\\te
mpinstall\\jython-2.0pa0\\jython.jar;c:\\jdk1.1.8\\lib\\classes.zip;e:\\dlc9
1b\\
java\\o4glrt.jar;e:\\dlc91b\\java\\progress.zip;.;.\\jpywork',
'.\\jpywork\\b.ja
va']
1  .\org\python\core\Py.java:1509: Method getParentFile() not found in class
jav
a.io.File.
        file.getParentFile().mkdirs();
                          ^
Note: 7 files use deprecated APIs.  Recompile with "-deprecation" for
details.
1 error, 1 warning

ERROR DURING JAVA COMPILATION... EXITING


> -----Original Message-----
> From:	bc...@wo... [SMTP:bc...@wo...]
> Sent:	Friday, November 03, 2000 6:01 AM
> To:	jyt...@li...
> Subject:	[Jython-dev] Another installer test.
> 
> Yet another installer test. Changes are:
> 
> - Non GUI installation option. This is triggered by the -o option to the
> Install program. The -o option expect a destination directory. By
> default only the core files will be installed. Additional installation
> modules can be selected by specifing the arguments "lib", "source"
> and/or "demo".
> 
>     java -cp . Install -o i:\temp\jython2.0pa0 lib source demo
> 
> - Added the os flavor "Mac_OS".
> 
> - OS identification option. Not all OS's are known in advance. The -f
> option allow users to specify the closest appoximation. Available OS's
> are "windows", "unix" and "mac".
> 
> 
> The installer is available from:
> 
>    ftp://jython.sourceforge.net/pub/jython/Install.class
> 
> A tarball of the modified LiftOff files:
> 
>   ftp://jython.sourceforge.net/pub/jython/liftoff-001102.tar
> 
> The config files for jython's use of LiftOff.
> 
>   ftp://jython.sourceforge.net/pub/jython/liftoff.props
>   ftp://jython.sourceforge.net/pub/jython/liftoff.filelist
> 
> regards,
> finn
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/jython-dev

Re: [Jython-dev] Re: execfile/eval classes not GC'ed

[<bc...@wo...>]

[Arun Sharma]

>I was using jpython-1.0.3 on Sun JDK 1.2.

That's right. The 1.0.3 version does indeed have this problem. It was
fixed before 1.1 (final). The best thing to do, is upgrade to a newer
version.

It is also fixed in Jython.

regards,
finn

[Jython-dev] Re: execfile/eval classes not GC'ed

[Arun S. <ads...@sh...>]

I was using jpython-1.0.3 on Sun JDK 1.2.

The last paragraph of this message seems to
confirm the presence of the problem:

http://www.egroups.com/message/jpython/1694

The problem can be reproduced with the following
test cases:

$ cat testeval.py
eval('1+2')

$ cat testexecfile.py
execfile('test.py')

$ cat test.py
print '1+2'

If you leave these programs running for a while and look at them
in top, you can see the leak.

    -Arun

-----Original Message-----
From: Samuele Pedroni <pe...@in...>
To: ar...@sh... <ar...@sh...>;
jyt...@li... <jyt...@li...>
Date: Monday, November 06, 2000 5:07 AM
Subject: execfile/eval classes not GC'ed


>Hi.
>
>Under which jvms does this happen?
>Can you produce a minimal example?
>
>As far as I know, if things are setup properly java machines
>collect classloaders and classes too.
>So it is possible that we can solve it.
>
>Your proposal sounds like a "desparate" workaround, have you analyzed the
>situation/code in order to exclude other possibilities? so could you
precisely
>explain why classes are not GC'ed or that's a jvm bug needing a workaround.
>
>At the moment part of the loading in jython is under reworking.
>I will try to track the problem, a failing example would be a nice
>start point. It is possible that references are kept around that
>block gc.
>
>regards,
>
>Samuele Pedroni
>
>
>------------- Begin Included Message -------------
>
>Bug #121738, was updated on 2000-Nov-05 23:32
>Here is a current snapshot of the bug.
>
>Project: Jython
>Category: None
>Status: Open
>Resolution: None
>Bug Group: None
>Priority: 5
>Summary: Memory leaks due to classes not being GC'ed
>
>Details:
>Going by previous exchanges on the mailing lists,
>this seems to be a known problem.
>
>When a execfile() or eval() is repeatedly
>executed in a long running java process, a
>new class gets created on every invocation.
>
>This class does not get garbage collected
>as long as the classloader which loaded it
>is around.
>
>This leads to a bloat of the java process
>size (not in the heap, but in the code blocks).
>
>Eval is kind of dispensable, but execfile is
>not. One easy fix would be to cache the generated
>class and reuse it the next time execfile is
>called.
>
>I can readily provide those patches. Is this
>acceptable or is a different solution already
>in the works ?
>------------- End Included Message -------------
>

[Jython-dev] execfile/eval classes not GC'ed

[Samuele P. <pe...@in...>]

Hi.

Under which jvms does this happen?
Can you produce a minimal example?

As far as I know, if things are setup properly java machines
collect classloaders and classes too.
So it is possible that we can solve it.

Your proposal sounds like a "desparate" workaround, have you analyzed the
situation/code in order to exclude other possibilities? so could you precisely 
explain why classes are not GC'ed or that's a jvm bug needing a workaround.

At the moment part of the loading in jython is under reworking.
I will try to track the problem, a failing example would be a nice
start point. It is possible that references are kept around that
block gc.

regards,

Samuele Pedroni


------------- Begin Included Message -------------

Bug #121738, was updated on 2000-Nov-05 23:32
Here is a current snapshot of the bug.

Project: Jython
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Memory leaks due to classes not being GC'ed

Details: 
Going by previous exchanges on the mailing lists,
this seems to be a known problem.

When a execfile() or eval() is repeatedly 
executed in a long running java process, a
new class gets created on every invocation.

This class does not get garbage collected
as long as the classloader which loaded it
is around.

This leads to a bloat of the java process
size (not in the heap, but in the code blocks).

Eval is kind of dispensable, but execfile is
not. One easy fix would be to cache the generated
class and reuse it the next time execfile is
called.

I can readily provide those patches. Is this
acceptable or is a different solution already
in the works ?
------------- End Included Message -------------

Re: [Jython-dev] Installer test

[Robert W. B. <rb...@di...>]

Installer test results:

platforms:
	Linux 2.2.12 (redhad 6.1, 6.2 and 'mixed' linux)
		Blackdown 1.2.2
		IBMJava2-13
	Solaris 2.8, SunOS 5.8
		Sun jdk 1.1.8

Linux:
	-gui install works fine.  
	    Shollow cosmetic issue: Fonts larger
	    than buttons on modal dialogs
	-installed scripts work  fine.

	-use of java -o Install ./jython results in
	 traceback-abort:  Note:  or varieties of full paths
	 tried with same results. Trace appended below.

Solaris:
	Gui and console install worked fine.
	generated scripts worked fine.


Tnx for -o :)

-robert

<BEGIN TRACE from linux console install>

try path /home/rbill/
SIGSEGV 11 (*) segmentation violation
	stackpointer=0xbffc0cf8

Full thread dump Classic VM (J2RE 1.3.0 IBM build cxdev-20000502, native threads):
    "Finalizer" (TID:0x40318708, sys_thread_t:0x80d3620, state:CW, native ID:0xc04) prio=8
	at java.lang.Object.wait(Native Method)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:114)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:129)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:168)
    "Reference Handler" (TID:0x40318750, sys_thread_t:0x80cf9f8, state:CW, native ID:0x803) prio=10
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:421)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
    "Signal dispatcher" (TID:0x40318798, sys_thread_t:0x80cbf00, state:CW, native ID:0x402) prio=5
    "main" (TID:0x403187e0, sys_thread_t:0x804f818, state:R, native ID:0x400) prio=5
	at Install.loadClassData(Install.java:197)
	at Install.loadClass(Install.java:242)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:257)
	at java.lang.Class.getMethods0(Native Method)
	at java.lang.Class.getDeclaredMethods(Class.java:1071)
	at java.io.ObjectStreamClass.computeSerialVersionUID(ObjectStreamClass.java:879)
	at java.io.ObjectStreamClass.access$4(ObjectStreamClass.java:856)
	at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:426)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.io.ObjectStreamClass.init(ObjectStreamClass.java:407)
	at java.io.ObjectStreamClass.lookupInternal(ObjectStreamClass.java:118)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:298)
	at net.sourceforge.liftoff.installer.Info.saveState(Info.java)
	at net.sourceforge.liftoff.installer.items.UninstallInfo.install(UninstallInfo.java:66)
	at net.sourceforge.liftoff.installer.items.InstallableContainer.install(InstallableContainer.java:145)
	at net.sourceforge.liftoff.installer.Install2.<init>(Install2.java)
	at net.sourceforge.liftoff.installer.Install2.main(Install2.java)
	at java.lang.reflect.Method.invoke(Native Method)
	at Install.main(Install.java:355)

Monitor pool info:
  Initial monitor count: 32
  Minimum number of free monitors before expansion: 5
  Pool will next be expanded by: 16
  Current total number of monitors: 32
  Current number of free monitors: 28

Monitor Pool Dump (inflated object-monitors):
  sys_mon_t:0x0804ee48 infl_mon_t: 0x0804ea40:
    java.lang.ref.Reference$Lock@40320180/40320188: owner "main" (0x804f818) 1 entry
	Waiting to be notified:
	    "Reference Handler" (0x80cf9f8)
  sys_mon_t:0x0804ee88 infl_mon_t: 0x0804ea60:
    java.lang.ref.ReferenceQueue$Lock@4031FDD0/4031FDD8: <unowned>
	Waiting to be notified:
	    "Finalizer" (0x80d3620)

JVM System Monitor Dump (registered monitors):
    ACS Heap lock: owner "main" (0x804f818) 1 entry
    System Heap lock: owner "main" (0x804f818) 1 entry
    Sleep lock: <unowned>
    Method trace lock: <unowned>
    UTF8 Cache lock: <unowned>
    Heap lock: owner "main" (0x804f818) 1 entry
    Rewrite Code lock: <unowned>
    Monitor Cache lock: owner "main" (0x804f818) 2 entries
    JNI Pinning lock: owner "main" (0x804f818) 1 entry
    JNI Global Reference lock: owner "main" (0x804f818) 1 entry
    Classloader lock: <unowned>
    Linking class lock: owner "main" (0x804f818) 1 entry
    Binclass lock: owner "main" (0x804f818) 1 entry
    Monitor Registry lock: owner "main" (0x804f818) 1 entry
    Thread queue lock: owner "main" (0x804f818) 2 entries

Thread identifiers (as used in flat monitors):
    ident 5 "Finalizer" (0x80d3620) ee 0x080d3450
    ident 4 "Reference Handler" (0x80cf9f8) ee 0x080cf828
    ident 3 "Signal dispatcher" (0x80cbf00) ee 0x080cbd30
    ident 2 "main" (0x804f818) ee 0x0804f648

Java Object Monitor Dump (flat & inflated object-monitors):
    Install@40318650/40318658
        locknflags 00020100 Flat locked by threadIdent 2. Entrycount 2
    java.lang.ref.ReferenceQueue$Lock@4031FDD0/4031FDD8
        locknflags 80000200 Monitor inflated infl_mon 0x0804ea60
    java.lang.ref.Reference$Lock@40320180/40320188
        locknflags 80000100 Monitor inflated infl_mon 0x0804ea40
    java.lang.Object@40546498/405464A0
        locknflags 00020000 Flat locked by threadIdent 2. Entrycount 1

SIGABRT 6 (*) abort process
	stackpointer=0xbffc097c

Full thread dump Classic VM (J2RE 1.3.0 IBM build cxdev-20000502, native threads):
    "Finalizer" (TID:0x40318708, sys_thread_t:0x80d3620, state:CW, native ID:0xc04) prio=8
	at java.lang.Object.wait(Native Method)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:114)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:129)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:168)
    "Reference Handler" (TID:0x40318750, sys_thread_t:0x80cf9f8, state:CW, native ID:0x803) prio=10
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:421)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
    "Signal dispatcher" (TID:0x40318798, sys_thread_t:0x80cbf00, state:CW, native ID:0x402) prio=5
    "main" (TID:0x403187e0, sys_thread_t:0x804f818, state:R, native ID:0x400) prio=5
	at Install.loadClassData(Install.java:197)
	at Install.loadClass(Install.java:242)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:257)
	at java.lang.Class.getMethods0(Native Method)
	at java.lang.Class.getDeclaredMethods(Class.java:1071)
	at java.io.ObjectStreamClass.computeSerialVersionUID(ObjectStreamClass.java:879)
	at java.io.ObjectStreamClass.access$4(ObjectStreamClass.java:856)
	at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:426)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.io.ObjectStreamClass.init(ObjectStreamClass.java:407)
	at java.io.ObjectStreamClass.lookupInternal(ObjectStreamClass.java:118)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:298)
	at net.sourceforge.liftoff.installer.Info.saveState(Info.java)
	at net.sourceforge.liftoff.installer.items.UninstallInfo.install(UninstallInfo.java:66)
	at net.sourceforge.liftoff.installer.items.InstallableContainer.install(InstallableContainer.java:145)
	at net.sourceforge.liftoff.installer.Install2.<init>(Install2.java)
	at net.sourceforge.liftoff.installer.Install2.main(Install2.java)
	at java.lang.reflect.Method.invoke(Native Method)
	at Install.main(Install.java:355)

Monitor pool info:
  Initial monitor count: 32
  Minimum number of free monitors before expansion: 5
  Pool will next be expanded by: 16
  Current total number of monitors: 32
  Current number of free monitors: 28

Monitor Pool Dump (inflated object-monitors):
  sys_mon_t:0x0804ee48 infl_mon_t: 0x0804ea40:
    java.lang.ref.Reference$Lock@40320180/40320188: owner "main" (0x804f818) 1 entry
	Waiting to be notified:
	    "Reference Handler" (0x80cf9f8)
  sys_mon_t:0x0804ee88 infl_mon_t: 0x0804ea60:
    java.lang.ref.ReferenceQueue$Lock@4031FDD0/4031FDD8: <unowned>
	Waiting to be notified:
	    "Finalizer" (0x80d3620)

JVM System Monitor Dump (registered monitors):
    ACS Heap lock: owner "main" (0x804f818) 1 entry
    System Heap lock: owner "main" (0x804f818) 1 entry
    Sleep lock: <unowned>
    Method trace lock: <unowned>
    UTF8 Cache lock: <unowned>
    Heap lock: owner "main" (0x804f818) 1 entry
    Rewrite Code lock: <unowned>
    Monitor Cache lock: owner "main" (0x804f818) 2 entries
    JNI Pinning lock: owner "main" (0x804f818) 1 entry
    JNI Global Reference lock: owner "main" (0x804f818) 1 entry
    Classloader lock: <unowned>
    Linking class lock: owner "main" (0x804f818) 1 entry
    Binclass lock: owner "main" (0x804f818) 1 entry
    Monitor Registry lock: owner "main" (0x804f818) 1 entry
    Thread queue lock: owner "main" (0x804f818) 2 entries

Thread identifiers (as used in flat monitors):
    ident 5 "Finalizer" (0x80d3620) ee 0x080d3450
    ident 4 "Reference Handler" (0x80cf9f8) ee 0x080cf828
    ident 3 "Signal dispatcher" (0x80cbf00) ee 0x080cbd30
    ident 2 "main" (0x804f818) ee 0x0804f648

Java Object Monitor Dump (flat & inflated object-monitors):
    Install@40318650/40318658
        locknflags 00020100 Flat locked by threadIdent 2. Entrycount 2
    java.lang.ref.ReferenceQueue$Lock@4031FDD0/4031FDD8
        locknflags 80000200 Monitor inflated infl_mon 0x0804ea60
    java.lang.ref.Reference$Lock@40320180/40320188
        locknflags 80000100 Monitor inflated infl_mon 0x0804ea40
    java.lang.Object@40546498/405464A0
        locknflags 00020000 Flat locked by threadIdent 2. Entrycount 1

<ENDTRACE>


On Thu, 2 Nov 2000, Finn Bock wrote:
> Yet another installer test. Changes are:
> 
> - Non GUI installation option. This is triggered by the -o option to the
> Install program. The -o option expect a destination directory. By
> default only the core files will be installed. Additional installation
> modules can be selected by specifing the arguments "lib", "source"
> and/or "demo".
> 
>     java -cp . Install -o i:\temp\jython2.0pa0 lib source demo
> 
> - Added the os flavor "Mac_OS".
> 
> - OS identification option. Not all OS's are known in advance. The -f
> option allow users to specify the closest appoximation. Available OS's
> are "windows", "unix" and "mac".
> 
> 
> The installer is available from:
> 
>    ftp://jython.sourceforge.net/pub/jython/Install.class
> 
> A tarball of the modified LiftOff files:
> 
>   ftp://jython.sourceforge.net/pub/jython/liftoff-001102.tar
> 
> The config files for jython's use of LiftOff.
> 
>   ftp://jython.sourceforge.net/pub/jython/liftoff.props
>   ftp://jython.sourceforge.net/pub/jython/liftoff.filelist
> 
> regards,
> finn
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/jython-dev
> 

Re: [Jython-dev] work in progress: cache

[<bc...@wo...>]

[Samuele Pedroni]

>> >Some questions:
>> >
>> >I would like to distinguish the support for dir() for java packages from
>> >the support for from <pkg> import *. I dislike the fact that dir
>> >force lazy loading, because __dir__ is used by from import * code.
>> >Lazy loading should be limited to the from import * case.
>> >The fact is that I want to minimize the "potential" robustness issues
>> >of the - in any case - necessary cache patch.
>> >Any remark or hint on this is welcome?

[me]

>> In principle, I don't see a problem if the "dir()" builtin on a java
>> package initialized the java classes, but your argumentation for doing
>> so is weak. The cache code must be robust in all cases. If it isn't, its
>> a bug that must be fixed.
>> 
>> Implementationwise, both "from xx import *" and "dir()" uses the
>> __dir__() hook, so do you propose make them diffrent?
>> 

[Samuele Pedroni]

>The patch that I'm working on do not contain the cache fix.
>
>It works as follows wrt java package:
>
>PyJavaPackage through findattr give access to all the classes in the package
>
>but the internal __dict__ contains only the actually loaded classes.
>
>My idea is that dir() returns the list of all names of classes but this not
>implies that they are actually in the internal __dict__,

This is OK. It is common that dir(o) returns more entries than exists in
the __dict__ (f.ex the contents of the __members__ and __methods__
attributes). 

Still, "dir(o)" results in a call to o.__dir__(), and "from x import *"
also results in a call to x.__dir__(). 

>Maybe my idea is bad or will probably break a lot of code, but
>I imagine there are few people doing:
> import jpkg
> 
> for clname in dir(jpkg):
>  print jpkg.__dict__[clname]

That is OK to break, since we at the same time add the workaround of
instead using:
  print getattr(jpkg, clname)

>Any suggestion is welcome.
>
>About robustness of the cache patch:
>
>1) without the patch we cannot have reloading
>2) I once written something about the technical aspects of what I imagine
> a patch could be, I repeat it here, kindly asking for feedback and opinions.

I didn't understand the problems and issues the first time around. I
still don't, but I will now at least try <wink>.

> The point is that 100% robustness seems to me not possible,

Then I think we should punt on it ..

> because we have to make assumptions about what lies behind the classloaders
> that we just receive in some sense without having control over them.

.. and make (or plan to make) the necessary hooks available so the
advanced reload programmer can add whatever assumptions that applies to
her application.

> But I agree that we should make it works without errors also in
> presence of very nasty classloader context, if one avoids  from jpkg import *.
>
>> This will introduce the cache fixing issue:
>> 
>> i) we cannot just use a Class->PyJavaClass cache, because this will
>> not support lazy loading (from jpkg import *).
>> 
>> ii) there are 2 options
>>   1) just a (classloader,classname)->PyJavaClass cache
>>   2) a Class->PyJavaClass and a cache like 1) that should be kept 
>synchronized.
>>      The (classloader,classname) cache will only be filled with classes
>>      that can incur in lazy loading.
>>      
>>   (1) is simpler to implent, but less efficient than (2)
>>   (2) is more complicated and error-prone
>>   
>> iii) the main problem is that we should be able to anticipate which classes
>> can incur in lazy loading and their "classloaders":
>> 
>>   jclass=loader.loadClass("...)
>> 
>> in general we will not have jclass.getClassLoader()==loader (*)

This false assumption seems to be at the core of the difficulties we
face. I'll have to make some example in order to understand when (*) is
false.


Example 1:

======= BEGIN X.java ======= 
public class X {
  public int value=6;
}
======= END ======= 

======= BEGIN Y.java ======= 
public class Y {
  public static void printX(X x) {
    System.out.println(x.value);
  }
}
======= END ======= 

>>>loader = jload.loader(".")
>>>print loader.__dict__
[]
>>>print loader.X
<jclass X at 11111>
>>>print loader.Y
<jclass Y at 22222>
>>>print loader.__dict__.keys()
['X', 'Y']
>>>loader.Y.printX(loader.X())
6
>>>loader.reload()
>>>print loader.__dict__.keys()
['X', 'Y']
>>>print loader.X
<jclass X at 33333>
>>>print loader.Y
<jclass Y at 44444>
>>>loader.Y.printX(loader.X())
6

The simplest example should work something like that and the assumption
(*) will always hold (correct me if I wrong!). The java classes that
gets resolved by the loader is always either loaded by the loader (and
can be reloaded) or is loaded by some system loader (and can't be
reloaded).

Example 1 covers uses such as rapid prototyping of java classes and test
drivers. It also includes IMO the majority of all request for java
reloading.



Example 2:

======= BEGIN Container.java ======= 
public interface Container {
  public void getName();
}
======= END ======= 

======= BEGIN Qcontainer.java ======= 
public class Qcontainer implemnts Container {
  public void getName() {
    return "Qcontainer";
  }
}
======= END ======= 

======= BEGIN lets/Qlet.java ======= 
package lets;
public class Qlet {
  public void doStart(Container contaner)
    System.out.println("My container is " + container.getName())
  }
}
======= END ======= 

>>>containerloader = jload.loader(".")
>>>container = containerloader.QContainer()
>>>containerloader.Container
<jclass Container at 11111>
#
# Here we tie together a list of loaders
>>>letsloader = jload.loader(".", containerloader)
>>>letsloader.lets.Qlet
<jclass lets.Qlet at 22222>
#
# Check if the resolved Container interface was loaded by the
# letsloader. It sholdn't be.
>>>print letsloader.__dict__.keys()
['lets.Qlet']
#
# The classes loaded by these two loaders are then interoperable.
>>>c = containerloader.QContainer()
>>>letsloader.lets.Qlet().doStart(c)
My container is QContainer
#
# This also holds after reloading the letsloader
>>>letsloader.reload()
>>>letsloader.lets.Qlet
<jclass lets.Qlet at 33333>
>>>letsloader.lets.Qlet().doStart(c)
My container is QContainer


If the containerloader is reloaded, I think all dependent loaders should
also be reloaded. Perhaps automaticly.

This example is modeled over the servlet idea. The QContainer is the
servlet server and the lets.Qlet is the servlet which can be reloaded
again and again.

>> In java2 the classloaders are organized in parent-child hierarchies,
>+ but the programmer can build also other relations,
>> with java11 classloaders world is flat, but this does not mean that
>> (*) always holds.
>> 
>> If we can have full control on things (f.ex. the load sets) we can
>> assume (*) to be true but that's not the case in general:

The situation where we do not have full control are?

- If the loaded java classes creates their own classloaders, and then
loads some classes which they wants to interoperable with classes loaded
by jython? Initially I have sympathy for this situation. Such a
situation does not have to work out of the box.
- Others? And please try to give example if you can.

>> a way to proceed is the following:
>> 
>> when we anticipate the "classloader" setting up things for lazy loading
>> we anticipate loader.
>> 
>> But when we recetive a loaded jclass we should be able to map its classloader
>> back to the guesses we make in the lazy loading setup case. And we have
>> also just the classloader to decide if a class can incur in lazy loading
>> because classes can just arrive from the pure java side of the world.
>> 
>> In order to do this we should make some assumptions (no solution in this
>> context can be strictly robust, with (2) we can add an option
>> that disable lazy loading and so the guess machinary when one knows
>> that things can go wrong) and should work for the common and
>> usual cases.

Of the top of my head (because I don't understand the situation where we
need to guess) I think we should punt on this. It is not like jython2.0
have to be the last word on java reloading. If we can handle the example
1 and maybe even example 2, I think we are multiple times better of then
all prevoiusly versions of JPython put together wrt. java reloading.

[example implementation snipped (again). I need to upgrade my background
and knowledge before I can evaluate it]

regards,
finn

Re: [Jython-dev] work in progress: cache

[Samuele P. <pe...@in...>]

Hi.


> >Some questions:
> >
> >I would like to distinguish the support for dir() for java packages from
> >the support for from <pkg> import *. I dislike the fact that dir
> >force lazy loading, because __dir__ is used by from import * code.
> >Lazy loading should be limited to the from import * case.
> >The fact is that I want to minimize the "potential" robustness issues
> >of the - in any case - necessary cache patch.
> >Any remark or hint on this is welcome?
> 
> In principle, I don't see a problem if the "dir()" builtin on a java
> package initialized the java classes, but your argumentation for doing
> so is weak. The cache code must be robust in all cases. If it isn't, its
> a bug that must be fixed.
> 
> Implementationwise, both "from xx import *" and "dir()" uses the
> __dir__() hook, so do you propose make them diffrent?
> 

The patch that I'm working on do not contain the cache fix.

It works as follows wrt java package:

PyJavaPackage through findattr give access to all the classes in the package

but the internal __dict__ contains only the actually loaded classes.

My idea is that dir() returns the list of all names of classes but this not
implies that they are actually in the internal __dict__,
Maybe my idea is bad or will probably break a lot of code, but
I imagine there are few people doing:
 import jpkg
 
 for clname in dir(jpkg):
  print jpkg.__dict__[clname]
  
Any suggestion is welcome.

About robustness of the cache patch:

1) without the patch we cannot have reloading
2) I once written something about the technical aspects of what I imagine
 a patch could be, I repeat it here, kindly asking for feedback and opinions.
 The point is that 100% robustness seems to me not possible,
 because we have to make assumptions about what lies behind the classloaders
 that we just receive in some sense without having control over them.
 But I agree that we should make it works without errors also in
 presence of very nasty classloader context, if one avoids  from jpkg import *.

> This will introduce the cache fixing issue:
> 
> i) we cannot just use a Class->PyJavaClass cache, because this will
> not support lazy loading (from jpkg import *).
> 
> ii) there are 2 options
>   1) just a (classloader,classname)->PyJavaClass cache
>   2) a Class->PyJavaClass and a cache like 1) that should be kept 
synchronized.
>      The (classloader,classname) cache will only be filled with classes
>      that can incur in lazy loading.
>      
>   (1) is simpler to implent, but less efficient than (2)
>   (2) is more complicated and error-prone
>   
> iii) the main problem is that we should be able to anticipate which classes
> can incur in lazy loading and their "classloaders":
> 
>   jclass=loader.loadClass("...)
> 
> in general we will not have jclass.getClassLoader()==loader (*)
> 
> In java2 the classloaders are organized in parent-child hierarchies,
+ but the programmer can build also other relations,
> with java11 classloaders world is flat, but this does not mean that
> (*) always holds.
> 
> If we can have full control on things (f.ex. the load sets) we can
> assume (*) to be true but that's not the case in general:
> a way to proceed is the following:
> 
> when we anticipate the "classloader" setting up things for lazy loading
> we anticipate loader.
> 
> But when we receive a loaded jclass we should be able to map its classloader
> back to the guesses we make in the lazy loading setup case. And we have
> also just the classloader to decide if a class can incur in lazy loading
> because classes can just arrive from the pure java side of the world.
> 
> In order to do this we should make some assumptions (no solution in this
> context can be strictly robust, with (2) we can add an option
> that disable lazy loading and so the guess machinary when one knows
> that things can go wrong) and should work for the common and
> usual cases.
> 
> What we need is a way to guess and a mapping from actual classloaders
> to the guesses:
> here is a proposal and discussion starting point:
> 
> I assume that sys.classLoader is not a hook (but in this case we should
> better protect it) and is set only once, if this is not the case things
> become more complicated (maybe impossible).
> 
>  normal lazy loading (the one that we have now and that will remain): 
>   guess = None // null
>  lazy loading from the context of a load sets (in the future):
>   guess = classloader-of-the-load-set
>   // the framework should force (*) to be true
>   
>   
>  mapping: 
>    we need the helper: 
>     
>     fromhier(jclass,classloader):
>      java11:
>       return jclass.classLoader == classloader or jclass.classLoader == None
>      java2:
>       try:
>        cl=jclass.classLoader
>       except <security>:
>        return 1
+       if cl==None:
+        return 1
>       try:
>        while 1:
>         if cl == classloader:
>          return 1
+         if classloader==None:
+             return 0
>         classloader = classloader.parent
>       except <security>:
>        pass
>       return 0
> 
>    sys.classLoader is sys.classLoader
>    rtloader is the loader of Python runtime (Py.class.getClassLoader())
>       
>    the_mapping(jclass):
>     if fromhier(jclass,rtloader) or fromhier(jclass,sys.classLoader):
>      return None
>     if jclass.classLoader is a load-set-classloader:
>      return it
>     return 'cannot incur in lazy loading'

regards, Samuele

Re: [Jython-dev] work in progress

[<bc...@wo...>]

[Samuele Pedroni ]

>I'm working on the precedence issue.
>I hope to have finished for ~monday.
>
>Everything we have discussed for it should be implemented, plus some
>other bug fixes.
>
>I also have implemented PackageManager through a hier. of abstract classes,
>this is an hook for future support for load sets.
>
>The patch/rewriting will be something finished but not definitive,
>something we can try and discuss on.
>
>We will have a symm. behaviour for dir/jar pkgs, I have merged
>PyJavaDir- and PyJavaPackage.

I'm looking forward to see it.

>Some questions:
>
>I would like to distinguish the support for dir() for java packages from
>the support for from <pkg> import *. I dislike the fact that dir
>force lazy loading, because __dir__ is used by from import * code.
>Lazy loading should be limited to the from import * case.
>The fact is that I want to minimize the "potential" robustness issues
>of the - in any case - necessary cache patch.
>Any remark or hint on this is welcome?

In principle, I don't see a problem if the "dir()" builtin on a java
package initialized the java classes, but your argumentation for doing
so is weak. The cache code must be robust in all cases. If it isn't, its
a bug that must be fixed.

Implementationwise, both "from xx import *" and "dir()" uses the
__dir__() hook, so do you propose make them diffrent?

regards,
finn

Re: [Jython-dev] work in progress

[<bc...@wo...>]

[cc'ed to Greg Stein]

[Samuele Pedroni]

>[..]
>I have read the archive of import-sig and looked at the version of imputil
>distributed with Python 2.0.
>
>Finn or somebody else knows what is the actual state of the issue?

It is my impression and recollection, that Greg Stein (the author of
imputil) wanted to move the implementation of dotted import into python
code. That should make it easier to change and experiment with. That
would have been a good and noble goal which could have helped JPython as
well. That was why I was watching the import-sig. 

Some design disagreements could not quite be worked out between Greg and
GvR. One of the issues that GvR wanted was the ability to use the
imputil to fake an import. Rather than running the code object and
creating an module object, the fake should just return the
text/identification of the imported module. That way freeze tools would
not have to re implement the entire dotted import algorithm all over
again. 

>will imputil substitute ihooks, the distributed version seems not finished
>and contains todos and referees and (Finn's) notes about what should be done
>to make it possibly work under J(P)ython.

I don't think that imputil will replace anything. At least not at the
moment. It is a useful frame work for making interesting import
features, like f.ex importing from a zip file or downloading module from
a CPAN library. 

>If it will be the future imp hooks framework, not ignoring it for the design
>of load sets is maybe a not bad design idea, but clearly imp hooks
>and load sets are in some sense orthogonal and the latter very java specific.

In its current state it is not the future of anything. It will stay a
somewhat obscure and undocumented module until Greg starts pushing it
again.

>[into the future]
>My first look impression, is that imputil design and import-sig discussion
>have ignored the jython side of the problem.

Yes. But then it is just our task to keep reminding the nice CPython
people that it also have to work with jython.  

>imputil should support RExec and the import practice of major py pkgs
>and extensions plus freeze and try to offer the primitives for mimicking
>the java load behaviours (url loading)....
>
>jython imp should support jpythonc, maybe somekind of poor freeze, java 
>reloading, mixing of classpath and sys.path ...
>
>My impression is that both world have something to learn from each other,

I agree.

>for example jython is maybe the right ground to decide what could make sense
>on sys.path (urls vs. 'importers' ...) and given the constraints for load sets
>design, that the concept of virtual pkg can sometimes be useful.
>
>On the other side jython lacks something like RExec, ok we have
>java security but it is (very) difficult to use it for python code directly,
>maybe we need an extension of RExec concepts that fits with java model:
>but that's a real challenge (completely aware of that!) and maybe not that
>much useful (very low prio ;)).

regards,
finn

[Jython-dev] work in progress

[Samuele P. <pe...@in...>]

Hi.

I'm working on the precedence issue.
I hope to have finished for ~monday.

Everything we have discussed for it should be implemented, plus some
other bug fixes.

I also have implemented PackageManager through a hier. of abstract classes,
this is an hook for future support for load sets.

The patch/rewriting will be something finished but not definitive,
something we can try and discuss on.

We will have a symm. behaviour for dir/jar pkgs, I have merged
PyJavaDir- and PyJavaPackage.

Some questions:

I would like to distinguish the support for dir() for java packages from
the support for from <pkg> import *. I dislike the fact that dir
force lazy loading, because __dir__ is used by from import * code.
Lazy loading should be limited to the from import * case.
The fact is that I want to minimize the "potential" robustness issues
of the - in any case - necessary cache patch.
Any remark or hint on this is welcome?

I have read the archive of import-sig and looked at the version of imputil
distributed with Python 2.0.

Finn or somebody else knows what is the actual state of the issue?

will imputil substitute ihooks, the distributed version seems not finished
and contains todos and referees and (Finn's) notes about what should be done
to make it possibly work under J(P)ython.

If it will be the future imp hooks framework, not ignoring it for the design
of load sets is maybe a not bad design idea, but clearly imp hooks
and load sets are in some sense orthogonal and the latter very java specific.


[into the future]
My first look impression, is that imputil design and import-sig discussion
have ignored the jython side of the problem.

imputil should support RExec and the import practice of major py pkgs
and extensions plus freeze and try to offer the primitives for mimicking
the java load behaviours (url loading)....

jython imp should support jpythonc, maybe somekind of poor freeze, java 
reloading, mixing of classpath and sys.path ...

My impression is that both world have something to learn from each other,

for example jython is maybe the right ground to decide what could make sense
on sys.path (urls vs. 'importers' ...) and given the constraints for load sets
design, that the concept of virtual pkg can sometimes be useful.

On the other side jython lacks something like RExec, ok we have
java security but it is (very) difficult to use it for python code directly,
maybe we need an extension of RExec concepts that fits with java model:
but that's a real challenge (completely aware of that!) and maybe not that
much useful (very low prio ;)).

regards, Samuele

[Jython-dev] Another installer test.

[<bc...@wo...>]

Yet another installer test. Changes are:

- Non GUI installation option. This is triggered by the -o option to the
Install program. The -o option expect a destination directory. By
default only the core files will be installed. Additional installation
modules can be selected by specifing the arguments "lib", "source"
and/or "demo".

    java -cp . Install -o i:\temp\jython2.0pa0 lib source demo

- Added the os flavor "Mac_OS".

- OS identification option. Not all OS's are known in advance. The -f
option allow users to specify the closest appoximation. Available OS's
are "windows", "unix" and "mac".


The installer is available from:

   ftp://jython.sourceforge.net/pub/jython/Install.class

A tarball of the modified LiftOff files:

  ftp://jython.sourceforge.net/pub/jython/liftoff-001102.tar

The config files for jython's use of LiftOff.

  ftp://jython.sourceforge.net/pub/jython/liftoff.props
  ftp://jython.sourceforge.net/pub/jython/liftoff.filelist

regards,
finn

Re: [Jython-dev] The next installer test.

[Jeff T. <je...@so...>]

All worked on redhat6.0/JDK1.2.2. Scripts were created with Unix EOF 
and worked fine.

--Jeff

On Wed, 1 Nov 2000, Finn Bock wrote:

> Hi 
> 
> A new updated test. Changes are:
[snip]
> The installer is available from:
> 
>    ftp://jython.sourceforge.net/pub/jython/Install.class

RE: [Jython-dev] The next installer test.

[Adam B. <ada...@gb...>]

Worked fine under

Windows NT SP6 with
IBM JDK 1.1.8 
Sun SDK2, JDK 1.2.2

Even overwrote the previous install successfully.

> -----Original Message-----
> From:	bc...@wo... [SMTP:bc...@wo...]
> Sent:	Thursday, November 02, 2000 4:49 AM
> To:	jyt...@li...
> Subject:	[Jython-dev] The next installer test.
> 
> Hi 
> 
> A new updated test. Changes are:
> 
> - The README.txt is included in the archive.
> 
> - The rules for locating the java.exe and jre.exe matches the old
> installer, but only on windows. I don't dare change anything for unix.
> I'll just assume that the liftoff author knows what he is doing on unix.
> 
> - The JAVA_HOME var is no longer set in the unix script.
> 
> - There is a MacActions class to handle mac specific behaviour, but it
> does not try to create any scripts. If the installer could do better,
> then let me know how. If someone have some help or hints for mac users I
> would like to show it in the readme panel.
> 
> - Installing as root user on unix should now respect the selected path
> instead of putting everything in /usr/doc/jython-2.0pa0/
> 
> - Scripts on unix should hopefully be written with unix line ending. 
> 
> 
> 
> The installer is available from:
> 
>    ftp://jython.sourceforge.net/pub/jython/Install.class
> 
> The modified LiftOff as a diff against the current LiftOff CVS:
> 
>   ftp://jython.sourceforge.net/pub/jython/liftoff-001101.diff
> 
> The config files for jython's use of LiftOff.
> 
>   ftp://jython.sourceforge.net/pub/jython/liftoff.props
>   ftp://jython.sourceforge.net/pub/jython/liftoff.filelist
> 
> regards,
> finn
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/jython-dev

[Jython-dev] The next installer test.

[<bc...@wo...>]

Hi 

A new updated test. Changes are:

- The README.txt is included in the archive.

- The rules for locating the java.exe and jre.exe matches the old
installer, but only on windows. I don't dare change anything for unix.
I'll just assume that the liftoff author knows what he is doing on unix.

- The JAVA_HOME var is no longer set in the unix script.

- There is a MacActions class to handle mac specific behaviour, but it
does not try to create any scripts. If the installer could do better,
then let me know how. If someone have some help or hints for mac users I
would like to show it in the readme panel.

- Installing as root user on unix should now respect the selected path
instead of putting everything in /usr/doc/jython-2.0pa0/

- Scripts on unix should hopefully be written with unix line ending. 



The installer is available from:

   ftp://jython.sourceforge.net/pub/jython/Install.class

The modified LiftOff as a diff against the current LiftOff CVS:

  ftp://jython.sourceforge.net/pub/jython/liftoff-001101.diff

The config files for jython's use of LiftOff.

  ftp://jython.sourceforge.net/pub/jython/liftoff.props
  ftp://jython.sourceforge.net/pub/jython/liftoff.filelist

regards,
finn

Re: [Jython-dev] Installer test

[<bc...@wo...>]

[Robert W. Bill]

>Installer test results:
>
>platforms:
>	Linux 2.2.12 (redhad 6.1, 6.2 and 'mixed' linux)
>		Blackdown 1.2.2
>		IBMJava2-13
>	Solaris 2.8, SunOS 5.8
>		Sun jdk 1.1.8
>
>Linux:
>	-If file already exists: error dialog is just an empty
>	 dialog box.

Ouch. I recall a lot of portability problem around modal dialogs.

>	-Generated scripts do not work- check CR-LF

Right. Fixed in next tryout.

>	-frequent "Java Object Monitor Dump" after
>	 jython_template.usix_sh convert then aborts
>	 installer

Does anyone know what causes this?

>	-jre used without jre option selected during install

For javasofts java2 the java.home is set to .../jdk1.2.1/jre (at least
on windows). So the executable used will be .../jdk1.2.1/jre/bin/java
even when jre isn't selected. The jre option controls only the name of
the executable, it's either java or jre. I believe the option only make
sense for the jdk1.1 series.

>Solaris:
>	-Hangs after copying of files is complete- no trace 
>	 (thats odd)

A file (the README.txt) was missing from the archive. Perhaps some bad
error handling caused the hang.

>	-Disregards selected paths and puts everything in 
>	 /usr/doc/jython-2.0pa0/

A feature that occurs when installing as root user. I have disabled this
feature in the next installer.

>	-Generated scripts do not work- CR-LF?
>	-jre set in generated scripts without jre options
>	 selected during install
>
>Note: Many linux webservers are without gui (all mine are).
>Is the DISPLAY (as in variable- not yelling :) necessary?  Can
>liftOff detect and do console install for this case? 

I'm not sure it can detect it, but it should support some kind of
non-gui mode, perhaps enable with a command line option. But LiftOff
does not (yet) support non-gui installation.

>I know I
>sound like a throw-back or gui-luddite, but I thought it worth
>mentioning.
>
>Is this the type of info that is helpful?  

Absolutely.

>Should
>corrected scripts be forwarded to compare with generated
>scripts that do not work- or are others way ahead of me? 

No need so far. I'll ask if I need the necessary changes.

regards,
finn

Re: [Jython-dev] Installer test

[Robert W. B. <rb...@di...>]

Installer test results:

platforms:
	Linux 2.2.12 (redhad 6.1, 6.2 and 'mixed' linux)
		Blackdown 1.2.2
		IBMJava2-13
	Solaris 2.8, SunOS 5.8
		Sun jdk 1.1.8

Linux:
	-If file already exists: error dialog is just an empty
	 dialog box.
	-Generated scripts do not work- check CR-LF
	-frequent "Java Object Monitor Dump" after
	 jython_template.usix_sh convert then aborts
	 installer
	-jre used without jre option selected during install
 
Solaris:
	-Hangs after copying of files is complete- no trace 
	 (thats odd)
	-Disregards selected paths and puts everything in 
	 /usr/doc/jython-2.0pa0/
	-Generated scripts do not work- CR-LF?
	-jre set in generated scripts without jre options
	 selected during install

Note: Many linux webservers are without gui (all mine are).
Is the DISPLAY (as in variable- not yelling :) necessary?  Can
liftOff detect and do console install for this case?  I know I
sound like a throw-back or gui-luddite, but I thought it worth
mentioning.

Is this the type of info that is helpful?  Should
corrected scripts be forwarded to compare with generated
scripts that do not work- or are others way ahead of me? 

Sorry if this is nebulous- so little time :(

-Robert

On Tue, 31 Oct 2000, Finn Bock wrote:

> Hi 
> 
> I have tried to create an installer for the current snapshot of jython.
> I have used the free (GPL) LiftOff program to create the self installing
> .class file.
> 
>    http://sourceforge.net/projects/liftoff/
> 
> The installer is 1.5 Mb and contains also the standard python library
> which have previously been distributed as pylib15x.jar
> 
>    ftp://jython.sourceforge.net/pub/jython/Install.class
> 
> We have not made any decisions that LiftOff should be used, so please
> look at this as part of an evaluation of installers.
> 
> I have only tested this on win2k (with jdk1.3, jdk1.1.7a & MS-jview
> 5.00.3229). Feedback from other platforms and JVMs is needed before we
> can decide whether LiftOff is useful to us. 
> 
> Please try the installer and post your experience, both good and bad,
> here on the list. Give special attention to the two generated scripts.
> With some luck these should work on unixes and windows. 
> 
> The text shown as license and readme should not be taken for anything
> other than examples. This also include the graphics used.
> 
> I had to fix some bugs in LiftOff which occurred on windows
> (line-ending, slash/backslash) and LiftOff is GPL so the modified
> version is here:
> 
>    ftp://jython.sourceforge.net/pub/jython/liftoff-001031.tar.gz
> 
> regards,
> finn
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/jython-dev
> 

Re: [Jython-dev] Installer test

[<bc...@wo...>]

>> This is a bit strange. The script didn't have the execute bit set? The
>> installer does a:
>>    Runtime.getRuntime().exec("chmod 755 " + fullname );
>> after creating the scripts. (The old installer did a "chmod 777" but I
>> think LiftOff is more correct here). Were there any messages shown in
>> the console window where you started the installer?
>
>The execute bits were set:
>
>-rwxr-xr-x   1 jeff     jeff          372 Nov  2 02:16 jython
>
>I think what happens is this: 
>
>On Unix, EOL corresponds to <LF>. On Windows it corresponds to <CR><LF>.
>So when the script is saved in DOS file format, the first line reads:
>
>#!/bin/sh<CR><LF>
>
>The shell reads everything up to EOF *on Unix*, ie <LF>, resulting in:
>
>#!/bin/sh<CR>
>
>It then tries to find the file, and can't because of the <CR>, so it
>fails with the error message:
>bash: ./jython: No such file or directory
>
>ie, it's saying "there's no file called "/bin/sh<CR>".
>
>Rather nasty :)

Yeah, but your explanation makes sense. Thanks.

regards,
finn

Re: [Jython-dev] Installer test

[Jeff T. <je...@so...>]

On Wed, 1 Nov 2000, Finn Bock wrote:

> 
> >> Please try the installer and post your experience, both good and bad,
> >> here on the list. Give special attention to the two generated scripts.
> >> With some luck these should work on unixes and windows. 
> 
> [Jeff Turner]
> 
> >Everything went fine (rh6.0, jdk1.2.2), except the two shell scripts
> >(jython and jythonc) were in DOS file format, 
> 
> Right, I'll fix that.
> 
> >and wouldn't execute:
> >
> >~/jython-2.0pa0$ ./jythonc
> >bash: ./jythonc: No such file or directory
> 
> This is a bit strange. The script didn't have the execute bit set? The
> installer does a:
>    Runtime.getRuntime().exec("chmod 755 " + fullname );
> after creating the scripts. (The old installer did a "chmod 777" but I
> think LiftOff is more correct here). Were there any messages shown in
> the console window where you started the installer?

The execute bits were set:

-rwxr-xr-x   1 jeff     jeff          372 Nov  2 02:16 jython

I think what happens is this: 

On Unix, EOL corresponds to <LF>. On Windows it corresponds to <CR><LF>.
So when the script is saved in DOS file format, the first line reads:

#!/bin/sh<CR><LF>

The shell reads everything up to EOF *on Unix*, ie <LF>, resulting in:

#!/bin/sh<CR>

It then tries to find the file, and can't because of the <CR>, so it
fails with the error message:
bash: ./jython: No such file or directory

ie, it's saying "there's no file called "/bin/sh<CR>".

Rather nasty :)

--Jeff

> 
> regards,
> finn
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/jython-dev
> 
> 

Re: [Jython-dev] Installer test

[<bc...@wo...>]

>> Please try the installer and post your experience, both good and bad,
>> here on the list. Give special attention to the two generated scripts.
>> With some luck these should work on unixes and windows. 

[Jeff Turner]

>Everything went fine (rh6.0, jdk1.2.2), except the two shell scripts
>(jython and jythonc) were in DOS file format, 

Right, I'll fix that.

>and wouldn't execute:
>
>~/jython-2.0pa0$ ./jythonc
>bash: ./jythonc: No such file or directory

This is a bit strange. The script didn't have the execute bit set? The
installer does a:
   Runtime.getRuntime().exec("chmod 755 " + fullname );
after creating the scripts. (The old installer did a "chmod 777" but I
think LiftOff is more correct here). Were there any messages shown in
the console window where you started the installer?

regards,
finn

Re: [Jython-dev] Installer test

[<bc...@wo...>]

[Jeff Turner]

>Is an installer necessary at all? Am I right in presuming it's so every
>user is forced to see the CNRI license and click "okay"? I've got nothing
>against installers, just curious.

Showing the license is just one of the things. Allowing users to choose
a destination and generating script files is another. But giving the
software a feel of being finished is IMO the most important part. 

So there will be an installer. 

The rest of us will of course continue to use the raw CVS <wink>.

regards,
finn

Re: [Jython-dev] Installer test

[<bc...@wo...>]

[me]

>The file was also too short on the ftp. I've re-upload it, please try
>again.

You will also need:

  ftp://jython.sourceforge.net/pub/jython/liftoff.props
  ftp://jython.sourceforge.net/pub/jython/liftoff.filelist

The .props is the one to open from within the builder.

regards,
finn

Re: [Jython-dev] Installer test

[Jeff T. <je...@so...>]

Is an installer necessary at all? Am I right in presuming it's so every
user is forced to see the CNRI license and click "okay"? I've got nothing
against installers, just curious.

--Jeff

On Wed, 1 Nov 2000, Finn Bock wrote:

> [Jeff Turner]
> 
> >Hmm.. so the use of a GPL'ed installer won't affect jython's license?
> 
> I don't think so, but I'm certainly not a license expert. The LiftOff
> author have answered the question here:
> 
>    http://www.geocrawler.com/archives/3/2137/2000/3/0/3412144/
> 
> It is my impression that we easily can comply with these requirements.
> The only requirement missing is to tell users (perhaps in the readme)
> where they can get the LiftOff sources.
> 
> It was not my intention to restrict the jython's license, and if that
> turns out to be the case, we must look for alternative installers.
> LiftOff is by far the most free installer I have found. I looked at:
> 
> FreeInstaller. Open source, with a license that is probably free but so
> long that I gave up reading it.
>    http://www.xenonsoft.demon.co.uk/freeinstaller.html
> 
> Instant installer. Almost open source. It uses some ObjectBlend classes
> which is not included.
>    http://gate02.halcyonsoft.com/opensource/installer/
> 
> regards,
> finn
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/jython-dev
> 

Re: [Jython-dev] Installer test

[<bc...@wo...>]

[Frode Reinsnes]

>Hi Finn,
>
>I try to run the installer on Mac and I got the folowing error:
>
>try path /Data1/Applications/Java/Jython/
>can not get flavour null for os 'Mac_OS'

I'll look into this, as well as the other problems reported. I'm not all
too surprised that Mac is the least supported platform, but of course
this must be corrected if we are to use LiftOff.

>Then I download liftoff-001031.tar.gz but I was not able to expand it
>because "zip entry is garbled".

The file was also too short on the ftp. I've re-upload it, please try
again.

regards,
finn