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

Re: [Jython-dev] catchall

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

[Samuele Pedroni]

>* Random notes on the cache issue and reloading (things I can work on):
>(1)
>[me]
>>From my side I should finish clarify the cache issue.
>Here are the pointers to last mails on this:
>[me] http://www.geocrawler.com/lists/3/SourceForge/7018/50/4602714/
>[Finn] http://www.geocrawler.com/lists/3/SourceForge/7018/50/4606179/
>
>Sorry if my explanations were confused,
>when I wrote
>> in general we will not have jclass.getClassLoader()==loader (*)
>I was making a general statement about java class loading where 'loader' is
>some java.lang.ClassLoader,
>and not an example of our reload support.
>We can surely support both examples imagined by Finn.
>The robustness issue is not directly related to reloading, and in any case
>we can set up some minimal
>requirements to classloaders passed to reload support. But if we want
>reloading we should fix the cache;
>and the cache fix I can imagine has a robustness issue related to
>*uniqueness* of PyJavaClasses when
>we have from ... import * lazy loading.
>
>I repeat this is related to uniqueness of PyJavaClasses not directly to
>reloading,
>and this is an example when things can go wrong.
>The setup is the following
>sys.classLoader is set to some foreign classloader (for example our code
>is some jythonc compiled code running under an application server (e.g.
>servlet container,...)).
>The code does from jpkg import *, jpkg contains e.g. a class Bean.
>At this point we put a lazy PyJavaClass pjc0 in our cache with key
>(null,"jpkg.Bean"),
>null meaning that we guess the class will come from runtime/sys.classLoader
>(or its parents).
>Now our code receives an instance inst0 of jpkg.Bean from java side of the
>world,
>and should find a corresponding PyJavaClass for it. Actually inst0.getName()
>== 'jpkg.Bean'.
>For cl:=inst0.getClass()
> sys.classLoader.loadClass("jpkg.Bean") == cl
>but cl.getClassLoader() is not sys.classLoader nor one of its parents.
>This is really a bad way to put up classloaders given the java2 rules but
>can happen (?).
>Now we are unable to link this instance with the pjc0 because it does not
>seem that
>its classloader come from sys.classLoader hierarchy => so we create a second
>PyJavaClass
>pjc1 != pjc0 and we lose uniqueness.
>That's is in some sense the only possible bad scenario, not really the
>common case and we have
>problem just because of lazy import *.

Let us for a moment say that we disable lazy loading. Each class in the
class list will then be resolved (through Py.findClassEx I think) into a
Class instance and the PyJavaClass will be complete including the link
from Class to PyJavaClass in PyJavaClass.classes.

When we in this theoretical senary receive the inst0 instance from the
java side its class either match an entry in PyJavaClass.classes and if
it does not match, we create a new entry with inst.getClass() as key.

So, lets add lazy loading. We now have an PyJavaClass.classes dict that
looks something like this:

  {
     org.python.core.PyJavaClass.class : PyJavaClass(PyJavaClass@1),
     "jpkg.Bean" : PyJavaClass(null),
  }

meaning that the PyJavaClass is fully initialized with its .class as key
and that jpkg.Bean is lazily loaded and uninitialized with the string
"jpkg.Bean" as key.

When we get a java instance inst0 from the java side we first check for
a lazy entry. We find jpkg.Bean which is then resolved using the same
classloaders setup as if the class was not lazy loaded. When the
PyjavaClass is initialized the lazy entry is removed and the dict looks
like this:

  {
     org.python.core.PyJavaClass.class : PyJavaClass(PyJavaClass@1),
     jpkg.Bean.class@2 : PyJavaClass(jpkg.Bean.class@2),
  }

Now the inst0.getClass() is searched in the dict. If it happens to be
the same as jpkg.Bean.class@2, the newly initialized PyJavaClass is
returned. If it isn't, a new entry is added.

  {
     org.python.core.PyJavaClass.class : PyJavaClass(PyJavaClass@1),
     jpkg.Bean.class@2 : PyJavaClass(jpkg.Bean.class@2),
     jpkg.Bean.class@3 : PyJavaClass(jpkg.Bean.class@3),
  }

This last dictionary would match the situation where we had disabled
lazy loading. The two jpkg.Bean classes would not be interoperable, but
lazily loaded class would work just like the ordinarily initialized
classes.

I still don't have a deep and intuitive understanding of the issues, so
there is likely something I have forgotten.

>(2) I think it would be great to have both unloading support (meaning
>discarding things from internal
>jython classes related caches) through explicit calls but also (optionally)
>under java2 lazily/implicitly through
>the use of weak-refs. I imagine a pluggable architecture for the caches.
>Should not be too difficult.

Cool.

>(3) For reloading also MakeProxies.makeClass should be changed:
>   - it leaks memory, blocking (together with the caches) proxies unloading,
>because
>     the direct proxies for classpath/sys.path loaded classes are defined
>directly in syspathJavaLoader.
>   - it does not support proxies with parents coming from classloaders
>different from syspathJavaLoader
>     and its ancestors,
>   this has already been written: we should use loaders for proxies with a
>local (direct parents) class pool to solve that,
>   this should work because there should be no intrapackage relationships
>issues (hope so ;) )

Right.

>  Maybe it is better to distinguish between a class implementing sys.path
>loading and a class for dynamic
>  loading of discardable code. Actually BytecodeLoader does both things.

Yes, that would be goodness. Much confusion in the past have its roots
in this double duty.

>[Finn]
>> >And with such
>> >a patch it should be possible to produce an experimental version
>> >of reloading support (in form of a python module using __import__ hook).
>>
>> Good. I would like to get broader feedback on the reloading issues, so
>> maybe some version of java reloading can go into 2.0-final marked as
>> experimental. I would also like Guido's view on how pythonic he consider
>> our java reload support to be.
>Hope that our best is enough ;), in any case if we should keep our reload
>support
>separate from runtime (because it is not enough pythonic) we will encouter
>the need
>of some ihooks/imputil-like support and suffer the destiny of import-sig,
>which has mostly ignored jython, otherwise people will not be able to hook
>importing for other purposes.
>
>* A framework for extending importing would also be great for jython, for
>example for poor-man freezing,
> putting support for everything directly in the runtime being not a good
>choice.
>
>* jythonc side
>+ package relative import has not been fixed yet.
>+ proposed --depend option.
>+ for the future:
>  - importing of compiled code into interp, and compiling code referring to
>separate comp results.
>  - (maybe) jythonc able to compile against a claspath/sys.path different
>from the classpath/sys.path under which is running
>
>* (mostly a potential users wish) it is really difficult to effectively use
>java security arch from jython and
>  for jython code,  some kind of rexec mixing java/python policies is maybe
>a necessary framework. (very complicated)
>* performance issues?(?)

I agree with all of this. I'm unsure how we should maintain this list.
The CPython people have their PEP-0042 for this. 


regards,
finn

Re: [Jython-dev] importing compiled code & cache...

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

Hi.

The reversed class -> module, inner class -> proxie approach is very nice
but I see the following problems:

1) with inner classes we have hard coupling => potential unwanted memory 
leakage.
2)
[Finn]
>1) A new option "--mainproxy" which will cause the MyBean$MyBean.class
>   proxy to be renamed to MyBean.class and the module is lost. So to 
>   get the current behaviour for existing applets, the --mainproxy
>   option must be specified. If the MyBean.MyBean class isn't a java
>   class, a warning is issued. No warning is issued for the loss of the
>   module, since it is done on behalf of the user.
The name clash issue technically is not only related to the ambiguity of
import MyBean, the code for the module will still be needed in some form,
e.g. the proxy constructor need to load it and this create an entry in 
sys.modules and here we encounter a second name clash if the proxy
is imported in jython.
The entry will avoid multiple load and be a meet-point for the proxies
from a single module, needed if we want to share global variables and avoid
replicas of the same module.
The choices for this case:
a) a module can have only one mainproxy, this loads the module
  anonymously and cache it in a static var. (too much coupling)
b) there could be many mainproxies but:
  * we reserve sys.modules somehow only for modules (code breakage?)
  * we build another cache for modules loaded through proxies
    (personnally I don't like having more caches around, what kind of
     key to use?)
  * given the module is lost, we rename the module, and issue
    a *warning* at compile time, we give the user an option to *choose* the
    name. We take care of this by mutual loading by the whole compilation.
  * having a name clash is an error. point.
or) we setup things in the following way, given this is just to support
the actual practice (by now we cannot load compiled modules nor proxies
effectively): we revert in this case (only in this case) to your first idea:
if MyBean is the mainproxy from MyBean.MyBean => import MyBean actually
imports the module MyBean, and that's what the proxie constructor need. But I 
imagine that users want to compile MyBean to a proxy MyBean and get the proxy 
with import MyBean.
or) import detects name clashes and raise an appropriate exception.


I would like to start coding the cache/MakeProxie fixes. Please, I would
like to read your words on that?

regards, Samuele.

Re: [Jython-dev] importing compiled code

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

On Mon, 20 Nov 2000 15:24:42 +0100 (MET), you wrote:

>From my viewpoint the main problem we are dealing with are the name 
>clashes, so if we want the new feature is better to revert the old practice:

Ok, I'm not in any way married to the existing default behaviour of
jythonc.

>user compiles a set of modules and marks through jythonc cmd-line options or
>"@sig"-like docs for which classes he wants to get pre-comp proxies,
>in principle he should avoid name clashes between proxies and modules, and
>such clashes are errors.
>But to be backward compatible if there is "just one" of such clashes,
>a proxie for the involved class (e.g MyBean) is produced with the right name
>and behind the scene the enclosing module is renamed (MyBean -> MyBean_home),

No. Changing the module name is wrong. Changing the name without giving
the users control over the new name is twice wrong.

>the assumption here is actually that people with the current usage of jythonc
>ignore the module at all, clearly a warning should be issued.
>2nd: the fact that actually things (module and proxie) are packaged together
>as inner class and class is nice, but if we can create more than a proxie 
>from a single py this does not work anymore. 

It doesn't? It works in the cases I have tried. Only the MyBean.MyBean
class will become the main proxy. The other classes are usable from java
as MyBean.MyOtherClass.

Here is another suggestion.

The default for jythonc is changed so that the MyBean.class is a module
and the proxy for MyBean.MyBean is a public static innerclass.
There will be two ways of changing this default:

1) A new option "--mainproxy" which will cause the MyBean$MyBean.class
   proxy to be renamed to MyBean.class and the module is lost. So to 
   get the current behaviour for existing applets, the --mainproxy
   option must be specified. If the MyBean.MyBean class isn't a java
   class, a warning is issued. No warning is issued for the loss of the
   module, since it is done on behalf of the user.

2) Marking the class with the text "@mainproxy" in the class's
   doc-string. If the MyBean.MyBean class is marked this way, the 
   module is overriden and lost. No warning is issued for the loss of
   the module. If other classes in MyBean is marked with "@mainproxy",
   jythonc will create separate MyOtherClass.java source file, one for
   each "@mainproxy" marked class.

I think it is Ok to lose the module when it happens based on a
deliberate user choice. (There haven't been a great demand for the
module).

Changing the default will very likely become a faq: "Why doesn't my
applet work anymore", but I think we can answers these questions as they
are asked.

>From the technical side
>a more loose coupling is quite better (also in single proxie case) w.r.t. to the 
>classloaders issues.

Right now there is a strict coupling between the module and the proxies:
the proxies accessed through the module will be loaded by the same
classloaded that loaded the module. That coupling should probably be
loosened in some way, I haven't looked into that.

regards,
finn

Re: [Jython-dev] catchall

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

Hi.

*  First.
[Finn]
> [Samuele on proxyclasses and module]
>
> >All this involves changes to runtime and jythonc, for the moment I would
> >prefer keep it low-prio.
>
> I agree.
Ok, let  us postpone that, but please, I would like to hear your opinion on
my last proposals
about clashes resulting in errors, and backward compatibility.

[Finn]
> - Update some of the text files: NEWS and README.
Both are important given your errata, the python 2.0 compatibility, and the
many broken things that now should work,
and the new load design with its rules.

An important note:
my patch ignores extendedClassLoader option, sys.path java loading is always
on, because having classpath taking over
should already avoids all problems. But it is still in the registry with a
meaningless comment and handled by Option.java...

* Random notes on the cache issue and reloading (things I can work on):
(1)
[me]
>From my side I should finish clarify the cache issue.
Here are the pointers to last mails on this:
[me] http://www.geocrawler.com/lists/3/SourceForge/7018/50/4602714/
[Finn] http://www.geocrawler.com/lists/3/SourceForge/7018/50/4606179/

Sorry if my explanations were confused,
when I wrote
> in general we will not have jclass.getClassLoader()==loader (*)
I was making a general statement about java class loading where 'loader' is
some java.lang.ClassLoader,
and not an example of our reload support.
We can surely support both examples imagined by Finn.
The robustness issue is not directly related to reloading, and in any case
we can set up some minimal
requirements to classloaders passed to reload support. But if we want
reloading we should fix the cache;
and the cache fix I can imagine has a robustness issue related to
*uniqueness* of PyJavaClasses when
we have from ... import * lazy loading.

I repeat this is related to uniqueness of PyJavaClasses not directly to
reloading,
and this is an example when things can go wrong.
The setup is the following
sys.classLoader is set to some foreign classloader (for example our code
is some jythonc compiled code running under an application server (e.g.
servlet container,...)).
The code does from jpkg import *, jpkg contains e.g. a class Bean.
At this point we put a lazy PyJavaClass pjc0 in our cache with key
(null,"jpkg.Bean"),
null meaning that we guess the class will come from runtime/sys.classLoader
(or its parents).
Now our code receives an instance inst0 of jpkg.Bean from java side of the
world,
and should find a corresponding PyJavaClass for it. Actually inst0.getName()
== 'jpkg.Bean'.
For cl:=inst0.getClass()
 sys.classLoader.loadClass("jpkg.Bean") == cl
but cl.getClassLoader() is not sys.classLoader nor one of its parents.
This is really a bad way to put up classloaders given the java2 rules but
can happen (?).
Now we are unable to link this instance with the pjc0 because it does not
seem that
its classloader come from sys.classLoader hierarchy => so we create a second
PyJavaClass
pjc1 != pjc0 and we lose uniqueness.
That's is in some sense the only possible bad scenario, not really the
common case and we have
problem just because of lazy import *.
(2) I think it would be great to have both unloading support (meaning
discarding things from internal
jython classes related caches) through explicit calls but also (optionally)
under java2 lazily/implicitly through
the use of weak-refs. I imagine a pluggable architecture for the caches.
Should not be too difficult.
(3) For reloading also MakeProxies.makeClass should be changed:
   - it leaks memory, blocking (together with the caches) proxies unloading,
because
     the direct proxies for classpath/sys.path loaded classes are defined
directly in syspathJavaLoader.
   - it does not support proxies with parents coming from classloaders
different from syspathJavaLoader
     and its ancestors,
   this has already been written: we should use loaders for proxies with a
local (direct parents) class pool to solve that,
   this should work because there should be no intrapackage relationships
issues (hope so ;) )
  Maybe it is better to distinguish between a class implementing sys.path
loading and a class for dynamic
  loading of discardable code. Actually BytecodeLoader does both things.

[Finn]
> >And with such
> >a patch it should be possible to produce an experimental version
> >of reloading support (in form of a python module using __import__ hook).
>
> Good. I would like to get broader feedback on the reloading issues, so
> maybe some version of java reloading can go into 2.0-final marked as
> experimental. I would also like Guido's view on how pythonic he consider
> our java reload support to be.
Hope that our best is enough ;), in any case if we should keep our reload
support
separate from runtime (because it is not enough pythonic) we will encouter
the need
of some ihooks/imputil-like support and suffer the destiny of import-sig,
which has mostly ignored jython, otherwise people will not be able to hook
importing for other purposes.

* A framework for extending importing would also be great for jython, for
example for poor-man freezing,
 putting support for everything directly in the runtime being not a good
choice.

* jythonc side
+ package relative import has not been fixed yet.
+ proposed --depend option.
+ for the future:
  - importing of compiled code into interp, and compiling code referring to
separate comp results.
  - (maybe) jythonc able to compile against a claspath/sys.path different
from the classpath/sys.path under which is running

* (mostly a potential users wish) it is really difficult to effectively use
java security arch from jython and
  for jython code,  some kind of rexec mixing java/python policies is maybe
a necessary framework. (very complicated)
* performance issues?(?)

regards, Samuele.

Re: [Jython-dev] importing compiled code

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

[Samuele on proxyclasses and module]

>All this involves changes to runtime and jythonc, for the moment I would
>prefer keep it low-prio.

I agree.

>Please, what are the plans for alpha1 and up to final 2.0?

Featurewise I think we have what we need for alpha1. I have some further
tests I want to perform on my own applications and I hope others also
try the version in CVS on some real world application and applets.

Apart from the code we need

- A license.
- There are still some bugs in the installer. (not including the latest
  bugs I introduced in pa3+4+5. I now know what caused them)
- Update some of the text files: NEWS and README.

Before beta I would like to:

- Fix some of the bugs when running CPython's test suite.
- Support the ucnhash and unicodedata modules.

>From my side I should finish clarify the cache issue. 

Right. I don't think it can get into alpha1 but the hooks to manage the
the caches should certainly go in before we enter beta.

>And with such
>a patch it should be possible to produce an experimental version
>of reloading support (in form of a python module using __import__ hook).

Good. I would like to get broader feedback on the reloading issues, so
maybe some version of java reloading can go into 2.0-final marked as
experimental. I would also like Guido's view on how pythonic he consider
our java reload support to be. 

regards,
finn

Re: [Jython-dev] using jpython

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

[Lars Marius Garshol]

>[...] I have an unreleased
>version that handles the new version, which I could make available if
>there is interest.  (Although it does need more development and
>testing.)

By all means, please show it. James Bullard have already expressed an
interrest in working at the jython / XML integration. 

regards,
finn

Re: [Jython-dev] importing compiled code

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

Hi.

[Finn]
> So maybe the ability to use the proxies directly from jython isn't so
> far away.
> 
> Rather than trying to decide if "z" should be a module or a class, we
> should give the user the option of choosing. Maybe as additional options
> to jythonc where the user can specify which of classes what should
> become main proxies (main proxies are real java classes, ordinary
> proxies are innerclasses). By default the module name will be importable
> as a module unless it is overridden as a main proxy. So
> 
>   jythonc z.py
> 
> would create a z.class proxy and no module, and
> 
>   jython --mainproxy="" z.py
> 
> would create a z.class module and a z$z.class proxy.
> There is probably better and more natural ways of specifing this, but I
> hope you get the general idea.

Yes, good point.
From my viewpoint the main problem we are dealing with are the name 
clashes, so if we want the new feature is better to revert the old practice:
user compiles a set of modules and marks through jythonc cmd-line options or
"@sig"-like docs for which classes he wants to get pre-comp proxies,
in principle he should avoid name clashes between proxies and modules, and
such clashes are errors.
But to be backward compatible if there is "just one" of such clashes,
a proxie for the involved class (e.g MyBean) is produced with the right name
and behind the scene the enclosing module is renamed (MyBean -> MyBean_home),
the assumption here is actually that people with the current usage of jythonc
ignore the module at all, clearly a warning should be issued.
2nd: the fact that actually things (module and proxie) are packaged together
as inner class and class is nice, but if we can create more than a proxie 
from a single py this does not work anymore. From the technical side
a more loose coupling is quite better (also in single proxie case) w.r.t. to the 
classloaders issues.
All this involves changes to runtime and jythonc, for the moment I would
prefer keep it low-prio.

Please, what are the plans for alpha1 and up to final 2.0?
From my side I should finish clarify the cache issue. And with such
a patch it should be possible to produce an experimental version
of reloading support (in form of a python module using __import__ hook).

regards, Samuele.

Re: [Jython-dev] importing compiled code

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

On Mon, 20 Nov 2000 02:11:58 +0100, you wrote:

>Hi.
>
>first some bugs status:
>1) I have put in place the fix for [ Bug #122610 ] SecEx in MS applerviewer.
>    http://sourceforge.net/bugs/?func=detailbug&bug_id=122610&group_id=12867
>2) Bug [ Bug #122793 ] Calling reload on java class loaded from sys.path
>cause NPE
>    http://sourceforge.net/bugs/?func=detailbug&bug_id=122793&group_id=12867
>    is clearly closed because actually reload for a jclass is nop,
>   or open if we want to keep it as reminder that we should implement
>reloading for jclasses <wink>.

Let us close as many bug reports as we can. If we want to have
remainders we can always open a new one with a more accurate
description.

>Now about importing compiled code:
>
>I'm not convinced about *my* proposal:
>
>[Finn]
>> ...
>> >Notice that with this design choice if someone load a compiled
>> >module through a java package it will get simply the java class
>> >not the module, for me this makes sense
>>
>> I fear it will be FAQ. In some setups you will get the module, in others
>> you will get the proxy. They have the same name so it is not obvious
>> which you happened to import.
>> ...
>>
>> I would not mind too much if the generated proxy classes wasn't
>> available from jython at all. As long as the module and all the classes
>> inside the module are available.
>>
>I'm not conviced that what we can quickly(?) implement is what people
>expect.
>It seems to me that jythonc is more there to build applets or make jython
>classes
>resemble java classes, such that people can forget about their jythonic
>nature.
>If someone subclasses a swing panel or builds a bean with jythonc I believe
>it expects a class
>not a module when he imports that back in the interpreter.

That is all true. I just don't think we can fullfill that expectation in
the more complicated situations:

=========== test260s1.py =========== 
import java
class test260s1(java.util.Vector):
   def foo(self):
       pass

class P(java.awt.Panel):
   pass

class foo:
   pass
=========== END =========== 

If the main code isn't run at some time during import, all the python
code (foo above) is lost. It is my believe (at the moment anyway) that
is is easier to explain that the test260s1 class is in fact called
test260s1.test260s1 then it is to explain what exactly that test260s1
thing is in the first place.

>I know this is just philosophy...
>but there is also a technical side:
>* as noticed the java class and the python module have the same name,
>  this is really a problem, e.g w.r.t. to sys.modules
>  I always felt that top-level jclasses should not end up in sys.modules but
>that
>  is what jython does. My viewpoint is that java classes are not modules...
>* actually one can get to import the compiled class, but constructed
>instances
>  do not work, I have done few experiments and read the code a bit, so maybe
>I'm missing something,
>  but this point could be solved making the PyJavaClass.__call__ return a
>python
>  class in this case, here it does not make sense to put a proxy around a
>proxy. 

Yes, that could be a likely solution.

> We should take care of
>  this also by subclassing. (see transcript at the end).
>* but the most serious issue is the following and this is an issue
>concerning both choices (class/pkg import):
>   we should be careful  choosing with which classloader we load things, in
>mixed java/jython code case
>   it is quite is easy and natural use the pre-built proxy from the java
>side (and this at java compilation time), I can imagine  that if   we are
>not careful we risk to load things twice and get a new series of interop
>problems ...
>* what should reload do?

He. I dunno, but if anyone wants to use reloading on a compiled python
class they shouldn't have compiled it in the first place.

>Are we in hurry to offer such a feature. 

No. I added it because I though it would be a small and easy change.
I'll remove my ModuleDictInit changes. 

>Personally I need more time to
>study the issue.
>Could you [Finn] list what is left to do (up to bugs), what should be in for
>alpha1 ... and the final release.
>For example the cache issue as a step toward reloading - I think - is
>important.
>
>About that there are still some questions around that I should answer you.
>I will post the answers together with a list of ideas (many are very
>low-prio).
>
>Comments are welcome.
>
>regards, Samuele
>
>----- an experiment
>This just indicates that the other choice (class import) is not hopeless,
>but this does not mean easy.
>
>Setup:
><Z.py>
>import java
>
>class Z(java.lang.Object):
> def value(self):
>  "@sig public int value()"
>  return 1
></Z.py>
>This gets compiled with jythonc to Z.class and Z$_PyInner.class.
>
><SZ.java>
>public class SZ {
> public static int svalue(Z z) {
>  return z.value();
> }
>}
></SZ.java>
>This gets compiled with javac against Z.class (from jythonc) to SZ.class.
>
>The bad news:
>Jython 2.0 pre-alpha on java1.3.0 (JIT: null)
>Type "copyright", "credits" or "license" for more information.
>>>> import Z
>>>> z=Z()
>>>> z.value()
>Traceback (innermost last):
>  File "<console>", line 1, in ?
>AttributeError: abstract method "value" not implemented
>
>The "good" news:
>Jython 2.0 pre-alpha on java1.3.0 (JIT: null)
>Type "copyright", "credits" or "license" for more information.
>>>> import sys
>>>> from java.lang import Class
>>>> import Z,SZ
>>>> (Z.getClassLoader(),SZ.getClassLoader()) # things loaded from sys.path
>(org.python.core.BytecodeLoader@ae1cf, org.python.core.BytecodeLoader@ae1cf)
>>>> sys.modules['Z']
><jclass Z at 8321686>
>>>> del sys.modules['Z'] # otherwise we get an exception
>>>> z=Class.newInstance(Z)
>>>> z
><Z.Z instance at 3180698>
>>>> z.value()
>1
>>>> sys.modules['Z']
><module Z at 4920025>
>>>> z1=Class.newInstance(Z)
>>>> sys.modules['Z']
><module Z at 4920025>
>>>> (SZ.svalue(z),SZ.svalue(z1))
>(1, 1)
>>>> class Y(Z):
>...  pass
>...
>>>> y=Y()
>>>> y.value()
>Traceback (innermost last):
>  File "<console>", line 1, in ?
>AttributeError: abstract method "value" not implemented
>>>> # but
>>>> class Y(z.__class__):
>...  pass
>...
>>>> y=Y()
>>>> y.value()
>1
>>>> # and most important
>>>> SZ.svalue(y)
>1
>>>> # seems to work.

So maybe the ability to use the proxies directly from jython isn't so
far away.

Rather than trying to decide if "z" should be a module or a class, we
should give the user the option of choosing. Maybe as additional options
to jythonc where the user can specify which of classes what should
become main proxies (main proxies are real java classes, ordinary
proxies are innerclasses). By default the module name will be importable
as a module unless it is overridden as a main proxy. So

  jythonc z.py

would create a z.class proxy and no module, and

  jython --mainproxy="" z.py

would create a z.class module and a z$z.class proxy.

There is probably better and more natural ways of specifing this, but I
hope you get the general idea.

regards,
finn

Re: [Jython-dev] using jpython

[Lars M. G. <la...@ga...>]

* Finn Bock
| 
| I tried to install xml under jython. To install I did this:
| 
| - Installed PyXML 0.6.2 under CPython2.0.
| - Copies CPython2.0's Lib/xml to jython Lib/xml directory.
| - Copies _xmlplus from the CPython2.0 directory to jython
|   Lib/_xmlplus  directory.
| - Added a "python.xml.sax.parser = xml.sax.drivers2.drv_xmlproc" to
|   my registry file.

This last step was wrong.  The xmlproc driver in the drivers2
directory is for an older version of SAX 2.  I have an unreleased
version that handles the new version, which I could make available if
there is interest.  (Although it does need more development and
testing.)
 
| Something works, but most of the tests from 0.6.2's test suite
| crashes or throws exceptions. There seems to be plenty of room for
| improvements to its jython integration.
| 
| If anyone will try to make these improvements, I would like to
| include the xml package in the jython installer. A CPython
| compatible API to xml processing would be very valuable.

I would love to help, but realistically my time is very limited both
this month and the next, so I doubt that I will get much done during
that time.  After that I may be able to help.

Meanwhile you may try to post to the XML-SIG mailing list and ask for
volunteers.

--Lars M.

Re: [Jython-dev] importing compiled code

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

Hi.

first some bugs status:
1) I have put in place the fix for [ Bug #122610 ] SecEx in MS applerviewer.
    http://sourceforge.net/bugs/?func=detailbug&bug_id=122610&group_id=12867
2) Bug [ Bug #122793 ] Calling reload on java class loaded from sys.path
cause NPE
    http://sourceforge.net/bugs/?func=detailbug&bug_id=122793&group_id=12867
    is clearly closed because actually reload for a jclass is nop,
   or open if we want to keep it as reminder that we should implement
reloading for jclasses <wink>.
3) [ Bug #122864 ] importing java packages
    http://sourceforge.net/bugs/?func=detailbug&bug_id=122864&group_id=12867
    has been closed by my patch that treats jars and dirs symmetrically.
4) [ Bug #122876 ] Import error with mixed classpath is solved by my patch
too.
    http://sourceforge.net/bugs/?func=detailbug&bug_id=122876&group_id=12867

2nd:
[Finn]
> >Why the InitModule and his support code are still left around?
> >Should we clean that?
>
> I have not removed it in the small hope that 3rd part modules which uses
> InitModule would continue to run with jython. I have not tested this, so
> this kind of compatibility may have been broken by some other change.
I think, it still works, e.g. PyDictionary still used it, I have just
changed that
but we can keep InitModule for 3rd part compatibility.

Now about importing compiled code:

I'm not convinced about *my* proposal:

[Finn]
> ...
> >Notice that with this design choice if someone load a compiled
> >module through a java package it will get simply the java class
> >not the module, for me this makes sense
>
> I fear it will be FAQ. In some setups you will get the module, in others
> you will get the proxy. They have the same name so it is not obvious
> which you happened to import.
> ...
>
> I would not mind too much if the generated proxy classes wasn't
> available from jython at all. As long as the module and all the classes
> inside the module are available.
>
I'm not conviced that what we can quickly(?) implement is what people
expect.
It seems to me that jythonc is more there to build applets or make jython
classes
resemble java classes, such that people can forget about their jythonic
nature.
If someone subclasses a swing panel or builds a bean with jythonc I believe
it expects a class
not a module when he imports that back in the interpreter.
I know this is just philosophy...
but there is also a technical side:
* as noticed the java class and the python module have the same name,
  this is really a problem, e.g w.r.t. to sys.modules
  I always felt that top-level jclasses should not end up in sys.modules but
that
  is what jython does. My viewpoint is that java classes are not modules...
* actually one can get to import the compiled class, but constructed
instances
  do not work, I have done few experiments and read the code a bit, so maybe
I'm missing something,
  but this point could be solved making the PyJavaClass.__call__ return a
python
  class in this case, here it does not make sense to put a proxy around a
proxy. We should take care of
  this also by subclassing. (see transcript at the end).
* but the most serious issue is the following and this is an issue
concerning both choices (class/pkg import):
   we should be careful  choosing with which classloader we load things, in
mixed java/jython code case
   it is quite is easy and natural use the pre-built proxy from the java
side (and this at java compilation time), I can imagine  that if   we are
not careful we risk to load things twice and get a new series of interop
problems ...
* what should reload do?

Are we in hurry to offer such a feature. Personally I need more time to
study the issue.
Could you [Finn] list what is left to do (up to bugs), what should be in for
alpha1 ... and the final release.
For example the cache issue as a step toward reloading - I think - is
important.

About that there are still some questions around that I should answer you.
I will post the answers together with a list of ideas (many are very
low-prio).

Comments are welcome.

regards, Samuele

----- an experiment
This just indicates that the other choice (class import) is not hopeless,
but this does not mean easy.

Setup:
<Z.py>
import java

class Z(java.lang.Object):
 def value(self):
  "@sig public int value()"
  return 1
</Z.py>
This gets compiled with jythonc to Z.class and Z$_PyInner.class.

<SZ.java>
public class SZ {
 public static int svalue(Z z) {
  return z.value();
 }
}
</SZ.java>
This gets compiled with javac against Z.class (from jythonc) to SZ.class.

The bad news:
Jython 2.0 pre-alpha on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import Z
>>> z=Z()
>>> z.value()
Traceback (innermost last):
  File "<console>", line 1, in ?
AttributeError: abstract method "value" not implemented

The "good" news:
Jython 2.0 pre-alpha on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import sys
>>> from java.lang import Class
>>> import Z,SZ
>>> (Z.getClassLoader(),SZ.getClassLoader()) # things loaded from sys.path
(org.python.core.BytecodeLoader@ae1cf, org.python.core.BytecodeLoader@ae1cf)
>>> sys.modules['Z']
<jclass Z at 8321686>
>>> del sys.modules['Z'] # otherwise we get an exception
>>> z=Class.newInstance(Z)
>>> z
<Z.Z instance at 3180698>
>>> z.value()
1
>>> sys.modules['Z']
<module Z at 4920025>
>>> z1=Class.newInstance(Z)
>>> sys.modules['Z']
<module Z at 4920025>
>>> (SZ.svalue(z),SZ.svalue(z1))
(1, 1)
>>> class Y(Z):
...  pass
...
>>> y=Y()
>>> y.value()
Traceback (innermost last):
  File "<console>", line 1, in ?
AttributeError: abstract method "value" not implemented
>>> # but
>>> class Y(z.__class__):
...  pass
...
>>> y=Y()
>>> y.value()
1
>>> # and most important
>>> SZ.svalue(y)
1
>>> # seems to work.

Re: [Jython-dev] Hangs on solaris.

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

On Sun, 19 Nov 2000, Finn Bock wrote:

> [Robert W. Bill]
> >=================================================================
> >Addition Solaris note:
> >
> >While testing the installers > jython-20pa2.class on Solaris,
> >all console messages are related to uninstall.
  <snip> 
> The pa3 version is broken and can not install. The pa4 version should
> work, it mainly contain some necesary changes for macs. So far the pa5
> have been purely internal. I have been trying to track down a bug on the
> SF shell machine (Linux 2.2.16-urw3 +  Linux_JDK_1.2_pre-release-v2)
> where one or sometime both script turned up empty (zero byte length).
> 
> I think I finally got it right, so the jython-20pa5 version is now the
> latest test version. Version pa5 also allow for a relative pathname as
> argument to the -o option.

Sorry for being unclear.  The above note was meant to read
as greater-than jython-20pa2.class.  I
tested pa3, pa4, and pa5.  I was unable to get any of the
three to work.  Expected behavior for 3, but 4&5 both create
EOFExceptions and uninstall error messages.

Here is the console (note: classpath already set):

[bash]:java jython-20pa5 -o /export/home/rbill/jython-20pa5
try path /export/home/rbill/
error while copying Tools/jythonc/main.py to /export/home/rbill/jython-20pa5/Tools/jythonc/main.py: java.io.EOFException: Unexpected end of ZLIB input stream
IOException java.io.EOFException: Unexpected end of ZLIB input stream
uninstall /export/home/rbill/jython-20pa5/ACKNOWLEDGMENTS
uninstall /export/home/rbill/jython-20pa5/Doc/api/org.python.util.PythonInterpreter.html
  <snip similar ~50 lines>
remove dir /export/home/rbill/jython-20pa5/installer
remove dir /export/home/rbill/jython-20pa5/data
  <snip similar ~15 lines>
can not remove dir /export/home/rbill/jython-20pa5
Abort
==================================================

I've tried other directories, UIDs, paths, etc (I was reaching
here :), but the exception/uninstall result is consistent.

Let me know if there is more info needed.

Regards,
Robert

Re: [Jython-dev] Hangs on solaris.

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

[Robert W. Bill]

>> PR#285
>> http://sourceforge.net/bugs/?func=detailbug&bug_id=122880&group_id=12867
>
>Jython-20pa2 raises SyntaxError appropriately, no wasted cpu
>nor seg_v.
>
>> PR#262
>> http://sourceforge.net/bugs/?func=detailbug&bug_id=122856&group_id=12867
>
>Raises SyntaxError appropriately, Jython-20pa2 does not hang.
>
>> PR#269
>> http://sourceforge.net/bugs/?group_id=12867&func=detailbug&bug_id=122863
>
>Raises SyntaxError appropriately, Jython-20pa2 does not block
>on missing comma.

Thank you. I'll close these reports.


>============================================================================
>Addition Solaris note:
>
>While testing the installers > jython-20pa2.class on Solaris,
>all console messages are related to uninstall.  The command
>line was:
>	 `java -classpath . jython-20pa4 -o /path/to/jython`,
>but only build.py was placed in /usedpath/jythonc/build.py.

The pa3 version is broken and can not install. The pa4 version should
work, it mainly contain some necesary changes for macs. So far the pa5
have been purely internal. I have been trying to track down a bug on the
SF shell machine (Linux 2.2.16-urw3 +  Linux_JDK_1.2_pre-release-v2)
where one or sometime both script turned up empty (zero byte length).

I think I finally got it right, so the jython-20pa5 version is now the
latest test version. Version pa5 also allow for a relative pathname as
argument to the -o option.

>============================================================================
>IBMJava note:
>
>I'm still lost on the seg fault with the
>installer+IBMJava.  While I have not clues, I thought I would
>append the output in case it's of use to others.  This output
>is from installer jython-20pa5 using 
>`java -classpath . jython-20pa5 -o /full/path/to/jythondir`
>and IBMJava2-13 on Linux.
>
><OUTPUT installer="jython-20pa5" jvm="IBMJava2-13">
>try path /home/rbill/test/
>target:jython SHA-1 Message Digest from SUN, <initialized>
>
>target:_top_
>getting stream
>...

That is my debug output. Can safely be ignored. The real dump starts
here:

>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:0x80d36a8, 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:0x80d0a18, 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:0x80cbf68, state:CW, native ID:0x402) prio=5
>    "main" (TID:0x403187e0, sys_thread_t:0x804f880, state:R, native ID:0x400) prio=5
>	at java.text.resources.LocaleElements.getContents(LocaleElements.java:371)
>	at java.util.ListResourceBundle.loadLookup(ListResourceBundle.java:172)
>	at java.util.ListResourceBundle.handleGetObject(ListResourceBundle.java:109)
>	at java.util.ResourceBundle.getObject(ResourceBundle.java:364)
>	at java.util.ResourceBundle.getObject(ResourceBundle.java:367)
>	at java.util.ResourceBundle.getObject(ResourceBundle.java:367)
>	at java.util.ResourceBundle.getStringArray(ResourceBundle.java:354)
>	at java.util.Calendar.setWeekCountData(Calendar.java:1483)
>	at java.util.Calendar.<init>(Calendar.java:781)
>	at java.util.GregorianCalendar.<init>(GregorianCalendar.java:351)
>	at java.util.GregorianCalendar.<init>(GregorianCalendar.java:323)
>	at java.util.SimpleTimeZone.<clinit>(SimpleTimeZone.java:901)
>	at java.util.TimeZone.<clinit>(TimeZone.java:467)
>	at java.util.GregorianCalendar.<init>(GregorianCalendar.java:323)
>	at java.util.Date.makeStaticCalendars(Date.java:1186)
>	at java.util.Date.getField(Date.java:1152)
>	at java.util.Date.getYear(Date.java:625)
>	at java.util.zip.ZipEntry.javaToDosTime(ZipEntry.java:286)
>	at java.util.zip.ZipEntry.setTime(ZipEntry.java:126)
>	at java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:127)
>	at net.sourceforge.liftoff.installer.items.InstallerLib.install(InstallerLib.java:102)
>	at net.sourceforge.liftoff.installer.items.InstallableContainer.install(InstallableContainer.java:145)
>	at net.sourceforge.liftoff.installer.Install2.<init>(Install2.java:107)
>	at net.sourceforge.liftoff.installer.Install2.main(Install2.java:129)
>	at java.lang.reflect.Method.invoke(Native Method)
>	at jython-20pa5.main(Install.java:355)

regards,
finn

Re: [Jython-dev] Hangs on solaris.

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

Jython Testing Report

As tested on 11/19/2000 on Solaris 2.8/SunOS 5.8
JVM==Sun 1.1.8 and Sun 1.2.1
Jython20 from installer==jython-20pa2  
(see not at end concerning installers >= pa4)

[Finn wrote:]
> We have three bugreports about jpython hanging on solaris when it is
> feed some illegal syntax. Could somebody with access to a solaris
> machine please give it a try and if the problem still exists with jython
> make a thread dump.
> 
> The bugs are:
> 
> PR#285
> http://sourceforge.net/bugs/?func=detailbug&bug_id=122880&group_id=12867

Jython-20pa2 raises SyntaxError appropriately, no wasted cpu
nor seg_v.

> PR#262
> http://sourceforge.net/bugs/?func=detailbug&bug_id=122856&group_id=12867

Raises SyntaxError appropriately, Jython-20pa2 does not hang.

> PR#269
> http://sourceforge.net/bugs/?group_id=12867&func=detailbug&bug_id=122863

Raises SyntaxError appropriately, Jython-20pa2 does not block
on missing comma.

============================================================================
Addition Solaris note:

While testing the installers > jython-20pa2.class on Solaris,
all console messages are related to uninstall.  The command
line was:
	 `java -classpath . jython-20pa4 -o /path/to/jython`,
but only build.py was placed in /usedpath/jythonc/build.py.

============================================================================
IBMJava note:

I'm still lost on the seg fault with the
installer+IBMJava.  While I have not clues, I thought I would
append the output in case it's of use to others.  This output
is from installer jython-20pa5 using 
`java -classpath . jython-20pa5 -o /full/path/to/jythondir`
and IBMJava2-13 on Linux.

<OUTPUT installer="jython-20pa5" jvm="IBMJava2-13">
try path /home/rbill/test/
target:jython SHA-1 Message Digest from SUN, <initialized>

target:_top_
getting stream
java.util.zip.ZipFile$1@5e2396f
read:278
getting stream
java.util.zip.ZipFile$1@47b396f
read:278
getting stream
java.util.zip.ZipFile$1@467b96f
read:278
yyr:java.io.InputStreamReader@63e396f
yyr2:278 0 512
yyr:java.io.InputStreamReader@63e396f
yyr1:-1 2 510
yyr:java.io.InputStreamReader@63e396f
yyr1:-1 0 512
yyr:java.io.InputStreamReader@63e396f
yyr2:-1 0 512
ds+ir close
target:jythonc SHA-1 Message Digest from SUN, <initialized>

target:_top_
getting stream
java.util.zip.ZipFile$1@30cbb96f
read:243
getting stream
java.util.zip.ZipFile$1@30f4396f
read:243
getting stream
java.util.zip.ZipFile$1@33b8396f
read:243
yyr:java.io.InputStreamReader@3241396f
yyr2:243 0 512
yyr:java.io.InputStreamReader@3241396f
yyr1:-1 2 510
yyr:java.io.InputStreamReader@3241396f
yyr1:-1 0 512
yyr:java.io.InputStreamReader@3241396f
yyr2:-1 0 512
ds+ir close
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:0x80d36a8, 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:0x80d0a18, 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:0x80cbf68, state:CW, native ID:0x402) prio=5
    "main" (TID:0x403187e0, sys_thread_t:0x804f880, state:R, native ID:0x400) prio=5
	at java.text.resources.LocaleElements.getContents(LocaleElements.java:371)
	at java.util.ListResourceBundle.loadLookup(ListResourceBundle.java:172)
	at java.util.ListResourceBundle.handleGetObject(ListResourceBundle.java:109)
	at java.util.ResourceBundle.getObject(ResourceBundle.java:364)
	at java.util.ResourceBundle.getObject(ResourceBundle.java:367)
	at java.util.ResourceBundle.getObject(ResourceBundle.java:367)
	at java.util.ResourceBundle.getStringArray(ResourceBundle.java:354)
	at java.util.Calendar.setWeekCountData(Calendar.java:1483)
	at java.util.Calendar.<init>(Calendar.java:781)
	at java.util.GregorianCalendar.<init>(GregorianCalendar.java:351)
	at java.util.GregorianCalendar.<init>(GregorianCalendar.java:323)
	at java.util.SimpleTimeZone.<clinit>(SimpleTimeZone.java:901)
	at java.util.TimeZone.<clinit>(TimeZone.java:467)
	at java.util.GregorianCalendar.<init>(GregorianCalendar.java:323)
	at java.util.Date.makeStaticCalendars(Date.java:1186)
	at java.util.Date.getField(Date.java:1152)
	at java.util.Date.getYear(Date.java:625)
	at java.util.zip.ZipEntry.javaToDosTime(ZipEntry.java:286)
	at java.util.zip.ZipEntry.setTime(ZipEntry.java:126)
	at java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:127)
	at net.sourceforge.liftoff.installer.items.InstallerLib.install(InstallerLib.java:102)
	at net.sourceforge.liftoff.installer.items.InstallableContainer.install(InstallableContainer.java:145)
	at net.sourceforge.liftoff.installer.Install2.<init>(Install2.java:107)
	at net.sourceforge.liftoff.installer.Install2.main(Install2.java:129)
	at java.lang.reflect.Method.invoke(Native Method)
	at jython-20pa5.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:0x0804eeb0 infl_mon_t: 0x0804eaa8:
    java.lang.ref.Reference$Lock@40320188/40320190: <unowned>
	Waiting to be notified:
	    "Reference Handler" (0x80d0a18)
  sys_mon_t:0x0804eef0 infl_mon_t: 0x0804eac8:
    java.lang.ref.ReferenceQueue$Lock@4031FDD8/4031FDE0: <unowned>
	Waiting to be notified:
	    "Finalizer" (0x80d36a8)

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

Thread identifiers (as used in flat monitors):
    ident 5 "Finalizer" (0x80d36a8) ee 0x080d34d8
    ident 4 "Reference Handler" (0x80d0a18) ee 0x080d0848
    ident 3 "Signal dispatcher" (0x80cbf68) ee 0x080cbd98
    ident 2 "main" (0x804f880) ee 0x0804f6b0

Java Object Monitor Dump (flat & inflated object-monitors):
    java.lang.ref.ReferenceQueue$Lock@4031FDD8/4031FDE0
        locknflags 80000200 Monitor inflated infl_mon 0x0804eac8
    java.lang.ref.Reference$Lock@40320188/40320190
        locknflags 80000100 Monitor inflated infl_mon 0x0804eaa8
    java.text.resources.LocaleElements@4049C380/4049C388
        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:0x80d36a8, 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:0x80d0a18, 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:0x80cbf68, state:CW, native ID:0x402) prio=5
    "main" (TID:0x403187e0, sys_thread_t:0x804f880, state:R, native ID:0x400) prio=5
	at java.text.resources.LocaleElements.getContents(LocaleElements.java:371)
	at java.util.ListResourceBundle.loadLookup(ListResourceBundle.java:172)
	at java.util.ListResourceBundle.handleGetObject(ListResourceBundle.java:109)
	at java.util.ResourceBundle.getObject(ResourceBundle.java:364)
	at java.util.ResourceBundle.getObject(ResourceBundle.java:367)
	at java.util.ResourceBundle.getObject(ResourceBundle.java:367)
	at java.util.ResourceBundle.getStringArray(ResourceBundle.java:354)
	at java.util.Calendar.setWeekCountData(Calendar.java:1483)
	at java.util.Calendar.<init>(Calendar.java:781)
	at java.util.GregorianCalendar.<init>(GregorianCalendar.java:351)
	at java.util.GregorianCalendar.<init>(GregorianCalendar.java:323)
	at java.util.SimpleTimeZone.<clinit>(SimpleTimeZone.java:901)
	at java.util.TimeZone.<clinit>(TimeZone.java:467)
	at java.util.GregorianCalendar.<init>(GregorianCalendar.java:323)
	at java.util.Date.makeStaticCalendars(Date.java:1186)
	at java.util.Date.getField(Date.java:1152)
	at java.util.Date.getYear(Date.java:625)
	at java.util.zip.ZipEntry.javaToDosTime(ZipEntry.java:286)
	at java.util.zip.ZipEntry.setTime(ZipEntry.java:126)
	at java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:127)
	at net.sourceforge.liftoff.installer.items.InstallerLib.install(InstallerLib.java:102)
	at net.sourceforge.liftoff.installer.items.InstallableContainer.install(InstallableContainer.java:145)
	at net.sourceforge.liftoff.installer.Install2.<init>(Install2.java:107)
	at net.sourceforge.liftoff.installer.Install2.main(Install2.java:129)
	at java.lang.reflect.Method.invoke(Native Method)
	at jython-20pa5.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:0x0804eeb0 infl_mon_t: 0x0804eaa8:
    java.lang.ref.Reference$Lock@40320188/40320190: <unowned>
	Waiting to be notified:
	    "Reference Handler" (0x80d0a18)
  sys_mon_t:0x0804eef0 infl_mon_t: 0x0804eac8:
    java.lang.ref.ReferenceQueue$Lock@4031FDD8/4031FDE0: <unowned>
	Waiting to be notified:
	    "Finalizer" (0x80d36a8)

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

Thread identifiers (as used in flat monitors):
    ident 5 "Finalizer" (0x80d36a8) ee 0x080d34d8
    ident 4 "Reference Handler" (0x80d0a18) ee 0x080d0848
    ident 3 "Signal dispatcher" (0x80cbf68) ee 0x080cbd98
    ident 2 "main" (0x804f880) ee 0x0804f6b0

Java Object Monitor Dump (flat & inflated object-monitors):
    java.lang.ref.ReferenceQueue$Lock@4031FDD8/4031FDE0
        locknflags 80000200 Monitor inflated infl_mon 0x0804eac8
    java.lang.ref.Reference$Lock@40320188/40320190
        locknflags 80000100 Monitor inflated infl_mon 0x0804eaa8
    java.text.resources.LocaleElements@4049C380/4049C388
        locknflags 00020000 Flat locked by threadIdent 2. Entrycount 1

</OUTPUT>

[Jython-dev] Hangs on solaris.

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

Hi,

We have three bugreports about jpython hanging on solaris when it is
feed some illegal syntax. Could somebody with access to a solaris
machine please give it a try and if the problem still exists with jython
make a thread dump.

The bugs are:

PR#285
http://sourceforge.net/bugs/?func=detailbug&bug_id=122880&group_id=12867

PR#262
http://sourceforge.net/bugs/?func=detailbug&bug_id=122856&group_id=12867

PR#269
http://sourceforge.net/bugs/?group_id=12867&func=detailbug&bug_id=122863

regards,
finn

Re: [Jython-dev] moduleDictInit is not called

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

[Samuele Pedroni]

>Hi.
>
>[Finn]
>> My *intention* for moduleInitDict was as a general hook which any java
>> class could implement if it wanted some control over its __dict__ when
>> it is imported. It was not only for compiled modules.
>For that we have classInitDict, which invocation seems to me in the right
>place.
>Clearly classDictInit is ok for manipulating the __dict__ but should not run
>a module main.
>Why the InitModule and his support code are still left around?
>Should we clean that?

I have not removed it in the small hope that 3rd part modules which uses
InitModule would continue to run with jython. I have not tested this, so
this kind of compatibility may have been broken by some other change.

>> So all together, your suggestion sounds better.

>I think we should put such code that deal with $_PyInner classes
>in loadBuiltin and loadFromPath. ((The builtins coming from compilation
> exceptions and cPickle_exc ... should then be better recompiled)).
>But then I imagine that a user would expect to be able to put
>a jar containing compiled modules in classpath and be able
>to import them. The simplest straightforward impl
>will not offer that, limiting the search of $_PyInner classes
>to sys.path as for .py and $py.class files.

Right.

>I do not know if can offer the latter with a clean semantics,
>but we can use for that openResourceAsStream.
>I'm also asking myself if we should consider the dynamic value
>of __path__ when looking for $_PyInner modules or not.
>(( Maybe all that is related to the big design question, wheter we want
>to load .py($py.class) also from classpath and have jars
>on sys.path... ))
>Notice that with this design choice if someone load a compiled
>module through a java package it will get simply the java class
>not the module, for me this makes sense 

I fear it will be FAQ. In some setups you will get the module, in others
you will get the proxy. They have the same name so it is not obvious
which you happened to import.

>but then we remain
>with the problem of how to enable the usage of compiled py classes
>as java classes from jython. 

I would not mind too much if the generated proxy classes wasn't
available from jython at all. As long as the module and all the classes
inside the module are available.

>You have always declared that this
>is really difficult and I should admit that I have not studied it yet,
>can you list what are the serious problem with that?

One problem that I have looked at is the way proxies stop their search
for attributes when they meet their first java superclass. As a result
subclasses of proxies can not find methods in the superclass and
overriding does not work:

------ x.py ------
import java
class x(java.lang.Object):
   def equals(self, other):
       print "equals", self, other
       return 0
------ END ------

Compile the x.py module to java class x.java.


>>> import x
>>> print type(x)
org.python.core.PyJavaClass
>>> a = x()
>>> print a
x@682b72
>>> print a.equals(a), a.equals(x)
1 0
>>>



>> Still, I feel a link is missing. Some way to go from x.class to
>> x$_PyInner.class, maybe as some public API in imp.java or Py.java.

>Sorry, I do not understand what  you mean with that.

I was thinking about the case where x.class and x$_PyInner.class exist
in a java package. A call to imp.load("x") will get the x.class, but
what if the programmer wanted the x.py module. Basicly the same problem
you described above.

Hmmm....

I think we should load the x.class when found in a java package. We can
decide if we should change this when we get more feedback from users.
So loadBuiltin and loadFromPath should look for $_PyInner as the last
option.

regards,
finn

BTW, the exceptions.java and cPickle_exceptions modules are just a
temporary hack. And so should the loadBuiltin be IMO. I have included an
old email where I try to describe the reasoning for the hack:


Subject: [Jython-dev] builtin exceptions
From: bc...@wo... (Finn Bock)
Date: Sat, 30 Sep 2000 19:32:09 GMT

Hi,

There is a problem with the exceptions module. At least there is if we
want to follow CPython's route where:

- string based std. exception are dropped.
- the exceptions module is builtin.

I think we want both. And when there no longer are string based std
exception as a fall back, we must be very certain that the exceptions
module can be loaded. So we also want to make it a builtin module.

I'd tried different experiments in the erratas. First I coded the
exceptions module as java class:

package org.python.modules;
public class exceptions  {
    public static class Exception extends PyObject {
        public static String __doc__ =
            "Base class for all standard Python exceptions.";

        public PyTuple args = Py.EmptyTuple;

        public Exception() {
        }

        public Exception(PyObject[] args, String[] kws) {
           this.args = new PyTuple(args);
        }

        public PyString __str__() {
            switch (args.__len__()) {
            case 0:
                return Py.newString("");
            case 1:
                return args.__getitem__(0).__str__();
            default:
                return args.__str__();
            }
        }

...
}

Initially this worked like a charm. From python this type can be
extended as usual and from java it can be extended as

    public static class PickleError extends exceptions.Exception {
        public PickleError() { }

        public PickleError(PyObject[] args, String[] kws) {
            super(args, kws);
        }

        public PyString __str__() {
            if (args.__len__() > 0 && args.__getitem__(0).__len__() > 0)
                return args.__getitem__(0).__str__();
            else
                return new PyString("(what)");
        }
    }



It does have some problems:

1) type(Exception) return TypeType, not ClassType

2) A java class does not allow changes to its __name__, nor can it
   control how it will be represented by str() and repr(). (Instances 
   of a java class can control it's representation, but the class
   itself can't).

3) A python class will not be able to inherit from two such exceptions.


Based on the experience, I decided to give up on exceptions.java and
instead built the exceptions module as a java class which create the
python classes by hand. Just like the exceptions.c does.

Unfortunately JPython have no API designed for this. The only way you
can create a python class is the jpythonc (and the dynamic code
compiler) creates python classes. That API (PyTableCode) is best suited
for mechanical code generation.

So in the latest errata I used jpythonc on exceptions.py, made it create
the file org/python/modules/exceptions.java and included this class in
the jar file.

Yes, it's Bad (tm).

We have to design a human usable API with which a programmer can create
python classes and populate it with functions and attributes. I just
fear that it isn't achievable before the first alpha. 

Our short term options are, as I see them:

1) Keep exceptions.py *and* use string based std exception as a
   fallback. I'll hate that because it makes it difficult to 
   create modules that must work with both string based and class 
   based exceptions.

2) Keep exceptions.py *without* any fallback if exceptions.py fail
   to load.

3) Include the generated exceptions.java (and the similarly generated
   cPickle_exceptions.java). 

I favor number 3.

R: [Jython-dev] [Bug #122610] SecEx in MS applerviewer

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

Hi.

so I will fix things that way.

regards, Samuele.

----- Original Message -----
From: Finn Bock <bc...@wo...>
To: <jyt...@li...>
Sent: Saturday, November 18, 2000 5:29 PM
Subject: Re: [Jython-dev] [Bug #122610] SecEx in MS applerviewer


> [me]
>
> >> A null frozenPackage parameter seems to occur when a module was
compiled
> >> without the --deep option. My interpretation of the meaning of "frozen"
> >> and "--deep" goes like this:
> >>
> >> 1) Using --deep (which results in Py.frozen == true) we can assume
> >>    a completely closed environment. Every external module and package
> >>    have been found by the compiler so there should be no need to search
> >>    the filesystem for anything.
> >>
> >> 2) Module that have been compile without the --deep option should be
> >>    importable and runnable as if they were compiled by CodeCompiler.
> >>    Such modules are compiled but they are not frozen. F.ex when running
> >>    such a module directly it should attempt to build the cache/packages
> >>    and should search the file system for modules and classes.
> >>
> >> The 2) type of compilation is not supported very well at the moment.
The
> >> cache/packages dir is created, but no .jars are cached because jythonc
> >> passes these properties to runMain():
> >>
> >>     python.packages.paths = ""
> >>     python.packages.directories = ""
> >>
> >> which creates a strange enviroment where java classes can't be found in
> >> submodules.
> >>
> >> Perhaps we should have an additional options to jythonc, say "--depend"
> >> which will track dependencies and compile all submodules but which does
> >> not set the Py.frozen flag.
>
> [Samuele]
>
> >So the bug is not really a bug.
> >When I removed the Py.frozen test in loadFromPath I was actually
> >thinking about 2).
> >
> >It seems to me that setting
> >
> >     python.packages.paths = ""
> >     python.packages.directories = ""
> >
> >is redudant.
> >
> >The right logic should be to avoid Py.frozen tests around
> >but to have in frozen code case (--deep):
> >
> > sys.path = []
> > and the cache not initialized.
> > and PackageManager, frozenModules filled with the params to initProxy/
> > runMain.
>
> Right.
>
> It would be a slight change of behavior for a frozen program that makes
> changes to sys.path, but I think that is acceptable.
>
> regards,
> finn
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/jython-dev
>

Re: [Jython-dev] moduleDictInit is not called

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

Hi.

[Finn]
> My *intention* for moduleInitDict was as a general hook which any java
> class could implement if it wanted some control over its __dict__ when
> it is imported. It was not only for compiled modules.
For that we have classInitDict, which invocation seems to me in the right
place.
Clearly classDictInit is ok for manipulating the __dict__ but should not run
a module main.
Why the InitModule and his support code are still left around?
Should we clean that?

> >My (not deeply tested) suggestion to get the desired functionality is =
> >not to use=20
> >moduleDictInit but simply to repeat the behaviour used when executing =
> >compiled
> >code outside of the interp:
> >the interp when looking for x should try not only x.py and x$py.class =
> >but
> >also x$_PyInner.class and then in this last case create an instance , =
> >getMain and execute
> >the obtained code in the dict of a new module.
>
> That will allow initialization of the module dict when importing the
> module and at the same time avoid the initialization when the proxy is
> used from python. In addition type(x) would be ModuleType instead of
> TypeType.
>
> So all together, your suggestion sounds better.
I think we should put such code that deal with $_PyInner classes
in loadBuiltin and loadFromPath. ((The builtins coming from compilation
 exceptions and cPickle_exc ... should then be better recompiled)).
But then I imagine that a user would expect to be able to put
a jar containing compiled modules in classpath and be able
to import them. The simplest straightforward impl
will not offer that, limiting the search of $_PyInner classes
to sys.path as for .py and $py.class files.
I do not know if can offer the latter with a clean semantics,
but we can use for that openResourceAsStream.
I'm also asking myself if we should consider the dynamic value
of __path__ when looking for $_PyInner modules or not.
(( Maybe all that is related to the big design question, wheter we want
to load .py($py.class) also from classpath and have jars
on sys.path... ))
Notice that with this design choice if someone load a compiled
module through a java package it will get simply the java class
not the module, for me this makes sense but then we remain
with the problem of how to enable the usage of compiled py classes
as java classes from jython. You have always declared that this
is really difficult and I should admit that I have not studied it yet,
can you list what are the serious problem with that?

> Still, I feel a link is missing. Some way to go from x.class to
> x$_PyInner.class, maybe as some public API in imp.java or Py.java.
Sorry, I do not understand what  you mean with that.

regards, Samuele

Re: [Jython-dev] [Bug #122610] SecEx in MS applerviewer

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

[me] 

>> A null frozenPackage parameter seems to occur when a module was compiled
>> without the --deep option. My interpretation of the meaning of "frozen"
>> and "--deep" goes like this:
>> 
>> 1) Using --deep (which results in Py.frozen == true) we can assume 
>>    a completely closed environment. Every external module and package
>>    have been found by the compiler so there should be no need to search
>>    the filesystem for anything.
>> 
>> 2) Module that have been compile without the --deep option should be
>>    importable and runnable as if they were compiled by CodeCompiler.
>>    Such modules are compiled but they are not frozen. F.ex when running
>>    such a module directly it should attempt to build the cache/packages
>>    and should search the file system for modules and classes.
>> 
>> The 2) type of compilation is not supported very well at the moment. The
>> cache/packages dir is created, but no .jars are cached because jythonc
>> passes these properties to runMain():
>> 
>>     python.packages.paths = ""
>>     python.packages.directories = ""
>> 
>> which creates a strange enviroment where java classes can't be found in
>> submodules.
>> 
>> Perhaps we should have an additional options to jythonc, say "--depend"
>> which will track dependencies and compile all submodules but which does
>> not set the Py.frozen flag.

[Samuele]

>So the bug is not really a bug.
>When I removed the Py.frozen test in loadFromPath I was actually
>thinking about 2).
>
>It seems to me that setting
>
>     python.packages.paths = ""
>     python.packages.directories = ""
>
>is redudant.
>
>The right logic should be to avoid Py.frozen tests around
>but to have in frozen code case (--deep):
>
> sys.path = []
> and the cache not initialized.
> and PackageManager, frozenModules filled with the params to initProxy/
> runMain.

Right. 

It would be a slight change of behavior for a frozen program that makes
changes to sys.path, but I think that is acceptable.

regards,
finn

Re: [Jython-dev] moduleDictInit is not called

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

On Sat, 18 Nov 2000 06:20:22 +0100, you wrote:

>First I should apologize if my patch is a little bit confusing.

Not at all. I had not thoroughly checked the execution path of the new
code.

>I tried the last commited version of the patch that should allow to load =
>compiled python modules
>and get them as working modules in the interp (based on invocation of =
>moduleDictInit).
>
>Given my patch, the point where  moduleInitDict is called is somehow =
>wrong.
>The point is that I have left createFromClass(String,InputStream) in the =
>code
>but this is no longer called and so createFromClass(String,Class) for =
>classes
>coming from sys.path.
>This make indeed sense: java classes are treated more symmetrically =
>indipendently from where they come
>as we wanted but so moduleInitDict is not called when supposed. Clearly =
>here we want to able
>to break the symmetry when this make sense and we are loading a compiled =
>module.

My *intention* for moduleInitDict was as a general hook which any java
class could implement if it wanted some control over its __dict__ when
it is imported. It was not only for compiled modules.

>The problem is that given the patch there is no clear, coherent point =
>where to put=20
>moduleDictInit invocation.

Right. It is a problem for the lazy loaded classes.

>My (not deeply tested) suggestion to get the desired functionality is =
>not to use=20
>moduleDictInit but simply to repeat the behaviour used when executing =
>compiled
>code outside of the interp:
>the interp when looking for x should try not only x.py and x$py.class =
>but
>also x$_PyInner.class and then in this last case create an instance , =
>getMain and execute
>the obtained code in the dict of a new module.

That will allow initialization of the module dict when importing the
module and at the same time avoid the initialization when the proxy is
used from python. In addition type(x) would be ModuleType instead of
TypeType.

So all together, your suggestion sounds better.

Still, I feel a link is missing. Some way to go from x.class to
x$_PyInner.class, maybe as some public API in imp.java or Py.java.

regards,
finn

[Jython-dev] moduleDictInit is not called

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

Hi.

First I should apologize if my patch is a little bit confusing.

I tried the last commited version of the patch that should allow to load =
compiled python modules
and get them as working modules in the interp (based on invocation of =
moduleDictInit).

Given my patch, the point where  moduleInitDict is called is somehow =
wrong.
The point is that I have left createFromClass(String,InputStream) in the =
code
but this is no longer called and so createFromClass(String,Class) for =
classes
coming from sys.path.
This make indeed sense: java classes are treated more symmetrically =
indipendently from where they come
as we wanted but so moduleInitDict is not called when supposed. Clearly =
here we want to able
to break the symmetry when this make sense and we are loading a compiled =
module.
The problem is that given the patch there is no clear, coherent point =
where to put=20
moduleDictInit invocation.
My (not deeply tested) suggestion to get the desired functionality is =
not to use=20
moduleDictInit but simply to repeat the behaviour used when executing =
compiled
code outside of the interp:
the interp when looking for x should try not only x.py and x$py.class =
but
also x$_PyInner.class and then in this last case create an instance , =
getMain and execute
the obtained code in the dict of a new module.
Let me know...=20
I can experiment with this.

regards, Samuele

Re: [Jython-dev] using jpython

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

[Lars Marius Garshol explains what jython needs to support the xml
package]

>[snipped]
>
>I hope this helps.

It is very helpfull. Thank you for the explanation.


I tried to install xml under jython. To install I did this:

- Installed PyXML 0.6.2 under CPython2.0.
- Copies CPython2.0's Lib/xml to jython Lib/xml directory.
- Copies _xmlplus from the CPython2.0 directory to jython
  Lib/_xmlplus  directory.
- Added a "python.xml.sax.parser = xml.sax.drivers2.drv_xmlproc" to
  my registry file.

Something works, but most of the tests from 0.6.2's test suite crashes
or throws exceptions. There seems to be plenty of room for improvements
to its jython integration.

If anyone will try to make these improvements, I would like to include
the xml package in the jython installer. A CPython compatible API to xml
processing would be very valuable.

regards,
finn

Re: [Jython-dev] [Bug #122610] SecEx in MS applerviewer

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

Hi.

> A null frozenPackage parameter seems to occur when a module was compiled
> without the --deep option. My interpretation of the meaning of "frozen"
> and "--deep" goes like this:
> 
> 1) Using --deep (which results in Py.frozen == true) we can assume 
>    a completely closed environment. Every external module and package
>    have been found by the compiler so there should be no need to search
>    the filesystem for anything.
> 
> 2) Module that have been compile without the --deep option should be
>    importable and runnable as if they were compiled by CodeCompiler.
>    Such modules are compiled but they are not frozen. F.ex when running
>    such a module directly it should attempt to build the cache/packages
>    and should search the file system for modules and classes.
> 
> The 2) type of compilation is not supported very well at the moment. The
> cache/packages dir is created, but no .jars are cached because jythonc
> passes these properties to runMain():
> 
>     python.packages.paths = ""
>     python.packages.directories = ""
> 
> which creates a strange enviroment where java classes can't be found in
> submodules.
> 
> Perhaps we should have an additional options to jythonc, say "--depend"
> which will track dependencies and compile all submodules but which does
> not set the Py.frozen flag.


So the bug is not really a bug.
When I removed the Py.frozen test in loadFromPath I was actually
thinking about 2).

It seems to me that setting

     python.packages.paths = ""
     python.packages.directories = ""

is redudant.

The right logic should be to avoid Py.frozen tests around
but to have in frozen code case (--deep):

 sys.path = []
 and the cache not initialized.
 and PackageManager, frozenModules filled with the params to initProxy/
 runMain.
 
regards
 
 

Re: [Jython-dev] [Bug #122610] SecEx in MS applerviewer

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

[Samuele Pedroni]

>I have partially tracked it down.
>Writing the patch I made the assumption (without checking the code: very =
>bad ;) ) that sys.path is set to []
>in the frozen code case. This is false in general.=20
>But there are also other related/similar potential bug in the =
>preexistent code.
>There is also a bug in jythonc which passes a null frozenPackage param.

A null frozenPackage parameter seems to occur when a module was compiled
without the --deep option. My interpretation of the meaning of "frozen"
and "--deep" goes like this:

1) Using --deep (which results in Py.frozen == true) we can assume 
   a completely closed environment. Every external module and package
   have been found by the compiler so there should be no need to search
   the filesystem for anything.

2) Module that have been compile without the --deep option should be
   importable and runnable as if they were compiled by CodeCompiler.
   Such modules are compiled but they are not frozen. F.ex when running
   such a module directly it should attempt to build the cache/packages
   and should search the file system for modules and classes.

The 2) type of compilation is not supported very well at the moment. The
cache/packages dir is created, but no .jars are cached because jythonc
passes these properties to runMain():

    python.packages.paths = ""
    python.packages.directories = ""

which creates a strange enviroment where java classes can't be found in
submodules.

Perhaps we should have an additional options to jythonc, say "--depend"
which will track dependencies and compile all submodules but which does
not set the Py.frozen flag.

regards,
finn

Re: [Jython-dev] cvs troubles

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

On Fri, 17 Nov 2000 03:53:30 +0100, you wrote:

>I tried to access the cvs as developer (to commit the patch) and got =
>stuck with the following:
>
>> cvs -t -z3 -d ped...@cv...:/cvsroot/jython co jython
...
>`/cvsroot/jython/jython': Permission denied

I'm guessing (and hoping) it is the 6 hour delay.

  http://sourceforge.net/docman/display_doc.php?docid=788&group_id=1

regards,
finn

[Jython-dev] [Bug #122610] SecEx in MS applerviewer

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

I have partially tracked it down.
Writing the patch I made the assumption (without checking the code: very =
bad ;) ) that sys.path is set to []
in the frozen code case. This is false in general.=20
But there are also other related/similar potential bug in the =
preexistent code.
There is also a bug in jythonc which passes a null frozenPackage param.

I will track these issues completely and make the necessary fixes.

regards, Samuele.