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

[Jython-dev] cvs troubles

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

Hi.

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
cvs checkout: notice: main loop with =
CVSROOT=3Dp...@cv...:/cvsroot/jython
 -> Starting server: ssh cvs.jython.sourceforge.net -l pedronis cvs =
server
ped...@cv...'s password:
S-> do_module (jython, Updating, , )
S-> fopen(/cvsroot/jython/CVSROOT/history,a)
S-> unlink(./CVS/Entries.Static)
S-> do_module (jython, Updating, , )
 -> unlink(CVS/Entries.Static)
cvs server: Updating jython
cvs server: failed to create lock directory in repository =
`/cvsroot/jython/jytho
n': Permission denied
cvs server: failed to obtain dir lock in repository =
`/cvsroot/jython/jython'
cvs [server aborted]: read lock failed - giving up

Any clue?

regards, Samuele

Re: AW: [Jython-dev] Jython-Tests was [a java load (...) patch]

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

[Schmidmeier, Arno]  

>	Can the tests run unattended?
>	Will and can you move your test suite to sourceforge?

I can make them available, but I will not commit them as part of the
sources. They are of too bad quality to be part of the official jython.

>	Are there any other formal test suites available?

There are formal tests Lib/test and parts of the CPython's test suite
can also be used with jython. I use this script, called from
Python2.0/Lib/test:

import regrtest
tests = [
    'test_augassign',
    'test_binascii',
    'test_binhex',
    'test_builtin',
    'test_contains',
    'test_cpickle',
    #'test_exceptions',
    #'test_extcall',
    #'test_format',
    'test_grammar',
    'test_hash',
    'test_long',
    'test_math',
    'test_md5',
    'test_MimeWriter',
    #'test_operations',
    'test_operator',
    'test_pickle',
    'test_pkg',
    #'test_pow',
    #'test_re',
    'test_rfc822',
    'test_sha',
    'test_sre',
    'test_string',
    'test_struct',
    'test_thread',
    'test_time',
    #'test_tokenize',
    'test_types',
    #'test_unicode',
    'test_unpack',
    'test_userdict',
    #'test_userlist',
    'test_userstring',
]
regrtest.main(tests)

regards,
finn

AW: [Jython-dev] Jython-Tests was [a java load (...) patch]

[Schmidmeier, A. <Arn...@si...>]

First of all thanx, for the great work till now!


> -----Ursprüngliche Nachricht-----
> Von:	bc...@wo... [SMTP:bc...@wo...]
> Gesendet am:	Donnerstag, 16. November 2000 17:18
> An:	jyt...@li...
> Betreff:	Re: [Jython-dev] a java load (...) patch
> 
> [Samuele Pedroni]
> 
> >Hi.
> >
> >I'm posting a (promised)
> >
> >java load patch:
> 
> Thanks Samuele. 
> 
> >the attachments are both gzip compressed context diff patches
> 
> It looks good. Very good. I've tested the patches with my 250+ tests
> that attempts to verify that old bugs haven't been reintroduced. Your
> changes passes with flying colours.
	[Schmidmeier, Arno]  
	Can the tests run unattended?
	Will and can you move your test suite to sourceforge?
	Are there any other formal test suites available?

> Lets get it committed ASAP. I have made you a developer and I will
> refrain from making any changes to the CVS until you are done.
> 
> regards,
> finn
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/jython-dev

Re: [Jython-dev] a java load (...) patch

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

[Samuele Pedroni]

>Hi.
>
>I'm posting a (promised)
>
>java load patch:

Thanks Samuele. 

>the attachments are both gzip compressed context diff patches

It looks good. Very good. I've tested the patches with my 250+ tests
that attempts to verify that old bugs haven't been reintroduced. Your
changes passes with flying colours.

Lets get it committed ASAP. I have made you a developer and I will
refrain from making any changes to the CVS until you are done.

regards,
finn

[Jython-dev] a java load (...) patch

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

Hi.

I'm posting a (promised)

java load patch:

the attachments are both gzip compressed context diff patches

core.patch is for org/python/core
 * deletes PyJavaDirPackage.java
 * adds
    CachedJarsPackageManager.java
    PathPackageManager.java
    SysPackageManager.java
jythonc.patch is for Tools/jythonc
 * adds yapm.py

(sorry, the following is descriptive, not much technical, nor complete)

what it implies: (most of these things have been discussed here on the list)

 * should fix the (by now mostly broken)
 relative import from package modules to be more python compliant.

 * Sets up a new (more coherent) precedence for import/loading:

  py pkg/modules > jclasses from classpath > jclasses from sys.path .

 Virtually one can think that the dynamic value of sys.path is appended
 to classpath. Clearly this is true up to the fact that classes in a "same"
 package split over classpath and sys.path do not have mutual
 access to their package protected member. That because loading
 from classpath and from sys.path involve two different classloaders.
 There is no fix for this but such a splitting is just a bit ill-minded.
 Classes in a java package shadowed by a python pkg can be accessed through
 the python pkg.

 *There is just one internal representation for java packages
  (PyJavaPackage -- PyJavaDirPackage is no longer used/necessary):

  all the (public) classes in a package - that can span over jars in
  classpath and directories both in classpath and sys.path - are retrieved.

  dir(jpkg) reports all their names and all subpackages names (just
  meaning subdirs, any hint for a better  policy is welcome)
  but does not change the package __dict__.

  from jpkg import * also retrieves all classes/subpkgs.

  As previously jars are scanned for classes at startup, but
  one can add info about more packages and jars through
  sys.add_package and sys.packageManager.addJarToPackages at any time.
  Here jars can be specified also trhough urls.

  PyJavaPackage has an attribute __file__ which is either None
  or the filename of the jar that contains the package, if this is
  unique (dirs do not count). Better policies suggestions are welcome here
too.

 * hooks for the future:

   given the changes for java packages handling, PackageManager
   had to be partly rewritten.
   More radically I have re-factored it as a hierarchy of
   classes:
    PackageManager (abstract)
    CachedJarsPackageManager (abstract)
    PathPackageManager (abstract)
    SysPackageManager (somehow the equivalent of the old PackageManager).

   These should help implementing the future architecture for reloading.
   The design can change a bit but the public interfaces should be ok
   as they are, maybe just incremented. In any case they are not intended
   to be really visible from the jython-side.
   I have also put some introductive javadoc comments in front of them and
   of their new members.
   Also looking forward in this direction each PyJavaPackage
   can be constructed giving a controlling PackageManager
   to which it delegates most of the logic it needs.

  * where necessary, Class.forName has been substituted to deal with
sys.path java loading.

jythonc-side:
 I have fixed jythonc to work with the new runtime. This fixes
 are more "tentative" and maybe a better design is possible, or I could
 have missed something.
 The fixes for depend.py and jar.py are based on
ClassLoader.openResourceAsStream
 (such a method has also been added to BytecodeLoader) and on a parallel
 to system-wide package manager that gathers information about the
 non-public/non-plain classes in packages.
 This has been constructed in jython using the introduced abstract classes
for
 package managers. Its definition is in the new file yapm.py,
 yapm just stands for "yet another package manager",
 suggestions for a more explicative name are welcome.
 These two "hacks" avoided me the rewriting of classes info
gathering/reading logic.
 As consequence, when building a jar (-jar opt)
the --core/--all/--addpackages
 classes are collected from the whole classpath/sys.path respecting the
ususal
 precedence for java loading, if someone is working with a class that
patches
 a jar by coming first in classpath, the patched version will end up in the
 builded jar.

 Important: the jythonc patch prepend python.jythonc.classpath to the
classpath passed
 to java compiler, this should make more sense than whole substitution,
 and also sys.path - coherently with the new rules - is appended at the end.

Notice:

1) I have not yet fixed the package relative import in jythonc.
2) I have left around some comments of the form "// ??pending: ...", what
   they point out should not be critical (e.g how to deal
   with some minimal diff between the jvms? what should/should
   not be supported? etc.) hints on them are welcome.
3) the patch has been tested with Lib/test, a selection of Python 2.0 tests
   (e.g. test_pkg is ok), some of the demo (a little applet, javaclasses,
embed ...) and
   jythonc, plus some ad-hoc examples related to rel pkg import & java
loading.
4) I hope I avoided nasty new bugs ;)

regards, Samuele Pedroni

Re: [Jython-dev] using jpython

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

* Finn Bock
| 
| What do we need to support the xml package in jython? There seems to
| missing at least a sax drv_xxx for the common java sax libraries.
| What else?

It depends to some extent on what you want.  Some of the packages,
like xmlproc, for example, can be used in Jython as they are.  I would
guess that minidom and probably also 4DOM can be used in Jython as
well.

I think the main thing that is missing is a SAX driver that can map
Java SAX 2.0 to Python SAX 2.0, since without this the Python DOMs
can't create DOM trees from XML documents.  This has been on my list
of things to do for a while, but at the moment I've been too busy to
do it.  It's planned that this driver will be a part of a package
called saxtools, which will again be part of the XML-SIG package.

But if anyone wants to write such a driver (shouldn't be hard), feel
free. I'll be happy to look over it and see that it is done correctly
and also to put it into the XML-SIG saxtools.

javadom.py should provide what is needed to use the Java DOM
implementations with the same interface as the Python ones.  Note that
this uses Java code only to create DOM trees from XML documents. It
hasn't been used for anything as far as I know, but it should still be
useful as it stands, although it may need some tweaks here and there.

eventdom by Paul Prescod is perhaps the most interesting piece of code
that is difficult to port.  It needs SAX, DOM and XPath in order to
work, and it's the XPath part that may be difficult.  It used to be
based on Dieter Maurer's PyXPath and it may be that it still is.
Whether PyXPath works in Jython or not I don't know.

I hope this helps.

--Lars M.

Re: [Jython-dev] using jpython

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

[James Bullard]

[cc'ed to Lars Marius Garshol]

>Hello, I am using Jpython for static Java and SQL generation from XML files.
>I have used the JDOM API from Python directly, but I definitely would like
>to see compliance with Python's standard XML library. Is anyone working on
>that? I would like to get involved with the Jython project - does anyone see
>compliance as valuable?

There are some support for java xml parsers in the xml package in
CPython2.0. Look at Lib/xml/sax/__init__.py for examples of this.

In the CVS version from the XML-SIG there are even more support (in
Lib/xml/dom/javadom.py and others).

I have no no clue on how it all fits together or how much we can
actually use. Which is why Lars is cc'ed, I hope he can shed some light
on this topic.

Questions to Lars:

What do we need to support the xml package in jython? There seems to
missing at least a sax drv_xxx for the common java sax libraries. What
else? 

regards,
finn

Re: [Jython-dev] using jpython

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

Hello Jim,

On Wed, 15 Nov 2000, James Bullard wrote:
> Hello, I am using Jpython for static Java and SQL generation from XML files.
> I have used the JDOM API from Python directly, but I definitely would like
> to see compliance with Python's standard XML library. Is anyone working on
> that? I would like to get involved with the Jython project - does anyone see
> compliance as valuable?
> 
> Jim

No, I don't know of anybody working on that.

Yes, compliance is good.

Has the xml-sig defined what to be compliant means?
Not meant to be rhetorical- it just seems They were
in a terrible rush to make 2.0.  I really don't know the
answer, so nobody take that the wrong way :)

Note: there is a wealth of java xml tools 
that have not left me wanting for CPython's import xml.  The
advantage comes from when you switch between CPython and
Jython and want to use the same modules- I have not needed
that yet, but it always seems a noble goal and a situation
where one learns from the other.

It seems that a good plan would be to join the Jython lists,
and the xml-sig lists, then narrow down what a
'compliant' patch would involve.  I'm sure jython and the
xml-sig could benefit.

Best wishes,
Robert

[Jython-dev] using jpython

[James B. <bu...@pe...>]

Hello, I am using Jpython for static Java and SQL generation from XML files.
I have used the JDOM API from Python directly, but I definitely would like
to see compliance with Python's standard XML library. Is anyone working on
that? I would like to get involved with the Jython project - does anyone see
compliance as valuable?

Jim

[Jython-dev] Jython graphics and logos

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

Hi, 

We need some new graphics for jython. I have put up a webpage with the
submissions so far.

   http://jython.sourceforge.net/graphics.html

regards,
finn

[Jython-dev] LiftOff and IBMJava on linux.

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

Hi, 

There have been a report where the LiftOff installer causes IBMJava2-13
to crash hard with a SIGSEGV. I have been unable to guess what it is in
liftoff that causes this, so I hope some of you can help.

To make it easier to test and experiment, I have put together a minimum
developer package for liftoff. 

- The jython-20pa2.class file is basicly a .zip file, and most 
  zip tools can extract the content. (The chmod may be wrong)

- Extract the net.sourceforge.liftoff.installer.* sources (nsli-src)
  into the same directory.

- Run the installer from the filesystem instead of the 
  jython-20pa2.class 

     java -classpath . net.sourceforge.liftoff.installer.Install2 \
          -o <outdir> demo lib source

  This have been consistently coredumping.


I hope that this setup makes it possible to make changes and test them
with a quick turnaround.

   ftp://jython.sourceforge.net/pub/jython/jython-20pa2.class
   ftp://jython.sourceforge.net/pub/jython/nsli-src.tar.gz


This is the stack trace at the time of the SIGSEGV:

    "main" (TID:0x403187e0, sys_thread_t:0x804f6e0, state:R, native ID:0x400) prio=5
	at java.io.BufferedInputStream.<init>(BufferedInputStream.java:161)
	at java.io.BufferedInputStream.<init>(BufferedInputStream.java:141)
	at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:90)
	at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:155)
	at java.net.URL.openStream(URL.java:813)
	at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:906)
	at net.sourceforge.liftoff.installer.source.ResourceSource.getFile(ResourceSource.java:77)
	at net.sourceforge.liftoff.installer.items.InstallerLib.install(InstallerLib.java:91)
	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)

regards,
finn

[Jython-dev] Jython logo

[Jorge M. J. <jmi...@se...>]

http://members.nbci.com/jmireles/jython/jython.html

[Jython-dev] RE: Jython-dev digest, Vol 1 #18 - 7 msgs

[Jorge M. J. <jmi...@se...>]

This is a quick and dirty logo (needs work, just an idea...)
 

> -----Mensaje original-----
> De:	jyt...@li...
> [SMTP:jyt...@li...]
> Enviado el:	jueves, 09 de noviembre de 2000 15:19
> Para:	jyt...@li...
> Asunto:	Jython-dev digest, Vol 1 #18 - 7 msgs
> 
> Send Jython-dev mailing list submissions to
> 	jyt...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.sourceforge.net/mailman/listinfo/jython-dev
> or, via email, send a message with subject or body 'help' to
> 	jyt...@li...
> 
> You can reach the person managing the list at
> 	jyt...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Jython-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. Updated docs. (Finn Bock)
>   2. work in progress (Samuele Pedroni)
>   3. Re: AW: [Jython-dev] work in progress (Samuele Pedroni)
>   4. AW: AW: [Jython-dev] work in progress (Schmidmeier, Arno)
>   5. Re: work in progress (Finn Bock)
>   6. Re: work in progress: rel files ctr (Samuele Pedroni)
>   7. Re: work in progress: rel files ctr (Samuele Pedroni)
> 
> --__--__--
> 
> Message: 1
> From: bc...@wo... (Finn Bock)
> To: jyt...@li...
> Date: Wed, 08 Nov 2000 21:24:49 GMT
> Subject: [Jython-dev] Updated docs.
> 
> 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
> 
> --__--__--
> 
> Message: 2
> Date: Thu, 9 Nov 2000 12:32:01 +0100 (MET)
> From: Samuele Pedroni <pe...@in...>
> Reply-To: Samuele Pedroni <pe...@in...>
> To: jyt...@li...
> Subject: [Jython-dev] work in progress
> 
> Hi.
> 
> Basically I have finished the tentative (open for discussion)
> patch/rewr.
> for loading precedence and merging the PyJava*Package classes.
> (I have setup also some hooks in PackageManager impl. and
> PyJavaPackage
> for the future load sets).
> I have to test it and then it will appear here.
> 
> I have some questions on assumptions I have made:
> 
> (I) For use as a 1st arg to a two args File ctr, an empty string is
> always
> explicitly expanded in jython codebase, sometimes with
>  if( dir.equals("") ) dir=".";
> sometimes with
>  if( dir.equals("") ) dir=<the value of
> System.getProperty("user.dir")>;
> The two methods should be aquivalent, does someone know how could they
> be different? which one should be preferred?
> (e.g. are there problems with the first method on a Mac jvm?)
> 
> (II) a) I have fixed (I hope) the relative import in package modules
> bug
> (runtime side, not jythonc yet),
> I had to rewrite the three args imp.importName was code dealt only
> with
> relative module import and not packages and was buggy wrt. to the top
> flag,
> 
> the runtime enforce and the old code assumed that if x.y.z is a key in
> 
> sys.modules (x.y.z loaded) also any subseq (e.g. x,x.y) will be
> present as a key 
> in sys.modules.
> I have used that assumption too, and took care that the runtime
> enforce its
> validity. Any one sees problem with that?
> 
> b) Is the following correct for CPython?, I have tryed to enforce it
> also
> in jython:
> 
> p0,p1 are py packages
> 
> if I do the following in a p1.a module:
> 
>  import sys
>  import p0.a.b.x
>  from p0.a.b.y import val
> 
> the keys p1.sys and p1.p0 will be added to sys.modules with value
> None.
> But no key of the form p1.p0.a... etc. (clearly the plain keys p0...
> and sys,
> binding to the real modules will be added too).
> 
> 
> regards, Samuele
> 
> 
> 
> --__--__--
> 
> Message: 3
> Date: Thu, 9 Nov 2000 13:54:54 +0100 (MET)
> From: Samuele Pedroni <pe...@in...>
> Reply-To: Samuele Pedroni <pe...@in...>
> Subject: Re: AW: [Jython-dev] work in progress
> To: jyt...@li...
> 
> Hi.
> 
> [Schmidmeier, Arno]
> >  Yes they can be different. e.g. py passing
> > -Duser.dir=~/something on the commandline of the java VM.
> > 	I do not know which should be preferred, but my feeling says me
> that
> > "" eqalsto System.getProperty("user.dir")should be preffered.
> > 	However there might be a problem is the access to
> System.getProperty
> > is restricted or if this property is not defined.
> > 	I suggest therefore something like:
> > 
> > 	String FileName=null;
> > 	try{
> > 		FileName=System.getProperty("user.dir",null);
> > 	}catch(SecurityException sec){}
> > 	if (FileName==null)
> > 		FileName=".";
> > 	...
> I should admit I had missed these aspects. In any case the expansion
> happen when interpreting classpath and sys.path, so "." is preferable.
> But I really worry about what happens on a Mac?
> Unfortunately I have no access to such a machine and its jvms.
> 
>  	[Schmidmeier, Arno]  
> > 	I do not understand this topic fully, I want to ask is following
> > scenario possible:
> > 	I have a java-package X with classes a and b.
> > 	on the classpath (sys or jython) there are two distinct entries
> > j1.jar and j2.jar. 
> > 	j1.jar contains a and j2.jar contains b. Is this possible?
> > 	Same for .py filesand directories.
> 
> The semantics for py modules will remain as in python, if one not
> plays with 
> __path__ a py packages span over just one directory and its subdirs.
> sys.path can contain only dirs (an extension for allowing zips and
> jars
> should be not too difficult but it depends on what happens on CPython
> side
> and for the moment I like to see what happen with the patch and get
> rid of
> old and (hopefully few) new bugs, extending things should be easier
> with a clean (so I hope) codebase.
> The support for relative imports inside py pkgs should work as in
> CPython.
> This should still be fixed in jythonc.
> Concerning java with the patch:
> * classpath is virtually extended with sys.path
> classpath take over sys.path.
> * py pkgs take over java pkgs, but the java classes in the shadowed
> pkg
>  can be accessed through the py package
> * dir and from import * for a java package now should really consider
> the union of everything that's is in the dirs/jar on classpath and in
> the
> dirs on sys.path.
> 
> regards, Samuele
> 
> 
> 
> 
> --__--__--
> 
> Message: 4
> From: "Schmidmeier, Arno" <Arn...@si...>
> To: "'Samuele Pedroni'" <pe...@in...>,
> jyt...@li...
> Subject: AW: AW: [Jython-dev] work in progress
> Date: Thu, 9 Nov 2000 15:19:05 +0100
> charset="iso-8859-1"
> 
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von:	Samuele Pedroni [SMTP:pe...@in...]
> > Gesendet am:	Donnerstag, 9. November 2000 13:55
> > An:	jyt...@li...
> > Betreff:	Re: AW: [Jython-dev] work in progress
> > 
> > Hi.
> > 
> > [Schmidmeier, Arno]
> > >  Yes they can be different. e.g. py passing
> > > -Duser.dir=~/something on the commandline of the java VM.
> > > 	I do not know which should be preferred, but my feeling says me
> that
> > > "" eqalsto System.getProperty("user.dir")should be preffered.
> > > 	However there might be a problem is the access to
> System.getProperty
> > > is restricted or if this property is not defined.
> > > 	I suggest therefore something like:
> > > 
> > > 	String FileName=null;
> > > 	try{
> > > 		FileName=System.getProperty("user.dir",null);
> > > 	}catch(SecurityException sec){}
> > > 	if (FileName==null)
> > > 		FileName=".";
> > > 	...
> > I should admit I had missed these aspects. In any case the expansion
> > happen when interpreting classpath and sys.path, so "." is
> preferable.
> 	[Schmidmeier, Arno]  I see here a problem with a bug in old
> versions
> of JPython.
> 	I do not know if it is fixed. It is pretty likely that . is on
> the
> classpath and also on sys.path.
> 	Older Versions of Jpython require a totally distinct classpath
> and
> sys.path.
> 	I am a bit scarry, only if this bug still exist, 
> 	that you might add unwanted . to the classpath or sys.path.
> 	If this bug is fixed . is ok for me.
> 
> > But I really worry about what happens on a Mac?
> > Unfortunately I have no access to such a machine and its jvms.
> > 
> >  	[Schmidmeier, Arno]  
> > > 	I do not understand this topic fully, I want to ask is following
> > > scenario possible:
> > > 	I have a java-package X with classes a and b.
> > > 	on the classpath (sys or jython) there are two distinct entries
> > > j1.jar and j2.jar. 
> > > 	j1.jar contains a and j2.jar contains b. Is this possible?
> > > 	Same for .py filesand directories.
> > 
> > The semantics for py modules will remain as in python, if one not
> plays
> > with 
> > __path__ a py packages span over just one directory and its subdirs.
> > sys.path can contain only dirs (an extension for allowing zips and
> jars
> > should be not too difficult but it depends on what happens on
> CPython side
> > and for the moment I like to see what happen with the patch and get
> rid of
> > old and (hopefully few) new bugs, extending things should be easier
> > with a clean (so I hope) codebase.
> 	[Schmidmeier, Arno]  I agree, extending things is much easier
> with a
> clean codebase.
> 	I vote for cleaning up first, then adding features.
> > The support for relative imports inside py pkgs should work as in
> CPython.
> > This should still be fixed in jythonc.
> > Concerning java with the patch:
> > * classpath is virtually extended with sys.path
> > classpath take over sys.path.
> > * py pkgs take over java pkgs, but the java classes in the shadowed
> pkg
> >  can be accessed through the py package
> 	[Schmidmeier, Arno]  I am a bit scary about this. Will following
> scenario work, with this design and implementation:
> 	I subclass a Java-Interface with Jython and create an instance
> a. 
> 	(Jython needs to load the Java Interface), it is currently not
> in
> the Java VM. (instance of java.lang.Class called IJP
> 	A second Java Thread needs the class for the Java-Interface so
> it
> query the Java-Classloader after the interface, the classloader
> returns IJ.
> 	Jython passes A to a Java-Object which was loaded by the
> Java-Classloader.
> 	Now is IJP==IJ?
> 
> > * dir and from import * for a java package now should really
> consider
> > the union of everything that's is in the dirs/jar on classpath and
> in the
> > dirs on sys.path.
> > 
> > regards, Samuele
> > 
> > 
> 	[Schmidmeier, Arno]  
> 	regards
> 		Arno 
> 
> --__--__--
> 
> Message: 5
> From: bc...@wo... (Finn Bock)
> To: jyt...@li...
> Subject: Re: [Jython-dev] work in progress
> Date: Thu, 09 Nov 2000 14:36:44 GMT
> 
> [Samuele Pedroni]
> 
> >Basically I have finished the tentative (open for discussion)
> patch/rewr.
> >for loading precedence and merging the PyJava*Package classes.
> >(I have setup also some hooks in PackageManager impl. and
> PyJavaPackage
> >for the future load sets).
> >I have to test it and then it will appear here.
> >
> >I have some questions on assumptions I have made:
> >
> >(I) For use as a 1st arg to a two args File ctr, an empty string is
> always
> >explicitly expanded in jython codebase, sometimes with
> > if( dir.equals("") ) dir=".";
> >sometimes with
> > if( dir.equals("") ) dir=<the value of
> System.getProperty("user.dir")>;
> >The two methods should be aquivalent, does someone know how could
> they
> >be different? which one should be preferred?
> >(e.g. are there problems with the first method on a Mac jvm?)
> 
> I think it would be better to let the File() ctor create and handle
> the
> aspect of relative files. I.e. 
> 
>             if (dirName.length() == 0)
>                 dirName = null;
>             File dir = new File(dirName, name);
> 
> It is not well defined, what will happen if the dirName == "", but a
> null directory value will create a relative file.
> Clearly both imp.loadFromPath and BytecodeLoader.open should use the
> same algorithm. That they doesn't just show that noone have had the
> Big
> Picture.
> 
> >(II) a) I have fixed (I hope) the relative import in package modules
> bug
> >(runtime side, not jythonc yet),
> >I had to rewrite the three args imp.importName was code dealt only
> with
> >relative module import and not packages and was buggy wrt. to the top
> flag,
> >
> >the runtime enforce and the old code assumed that if x.y.z is a key
> in 
> >sys.modules (x.y.z loaded) also any subseq (e.g. x,x.y) will be
> present as a key 
> >in sys.modules.
> >I have used that assumption too, and took care that the runtime
> enforce its
> >validity. Any one sees problem with that?
> 
> No. From my understanding that is what sys.modules should contain.
> 
> >b) Is the following correct for CPython?, I have tryed to enforce it
> also
> >in jython:
> >
> >p0,p1 are py packages
> >
> >if I do the following in a p1.a module:
> >
> > import sys
> > import p0.a.b.x
> > from p0.a.b.y import val
> >
> >the keys p1.sys and p1.p0 will be added to sys.modules with value
> None.
> >But no key of the form p1.p0.a... etc. (clearly the plain keys p0...
> and sys,
> >binding to the real modules will be added too).
> 
> That is indeed what CPython does. From the source, the None values
> appears to some kind of optimizations, inserted just to show that
> these
> module names does not exists. But it is difficult to be sure, the
> dotted-import source code in CPython is not much better than Jython's.
> 
> regards,
> finn
> 
> --__--__--
> 
> Message: 6
> Date: Thu, 9 Nov 2000 16:02:55 +0100 (MET)
> From: Samuele Pedroni <pe...@in...>
> Reply-To: Samuele Pedroni <pe...@in...>
> Subject: Re: [Jython-dev] work in progress: rel files ctr
> To: jyt...@li...
> 
> Hi.
> 
> Really just a detail.
> [Finn Bock]
> > I think it would be better to let the File() ctor create and handle
> the
> > aspect of relative files. I.e. 
> > 
> >             if (dirName.length() == 0)
> >                 dirName = null;
> >             File dir = new File(dirName, name);
> > 
> > It is not well defined, what will happen if the dirName == "", but a
> > null directory value will create a relative file.
> 
> Reading the sun docs:
> 
> http://java.sun.com/j2se/1.3/docs/api/java/io/File.html#File(java.lang
> .String, 
> java.lang.String)
> 
> The contrary seems true, at least for java2. So that "" is the right
> choice
> to get a "rel" dir.
> 
> But my fear is really for java1.1 and the Macs.
> The old sun jdk1.1 doc is mostly unclear.
> 
> regards, Samuele
> 
> 
> --__--__--
> 
> Message: 7
> Date: Thu, 9 Nov 2000 16:09:53 +0100 (MET)
> From: Samuele Pedroni <pe...@in...>
> Reply-To: Samuele Pedroni <pe...@in...>
> Subject: Re: [Jython-dev] work in progress: rel files ctr
> To: jyt...@li...
> 
> Sorry, I have tried it concretely.
> 
> The java 1.2 doc is confused too.
> 
> You [Finn] are right, null seems to do the right job, at least
> with java2.
> 
> regards, Samuele.
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/jython-dev
> 
> 
> End of Jython-dev
> Digest_______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/jython-dev

Re: [Jython-dev] Jython homepage

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

[Robert W. Bill kindly suggest modification to the website]

Thanks, your comments have been added.

>Q- are these pages really generated as noted in their
>comments?  

Yes, but I have modified the JpyGenerator class in the ht2html package.
I'll make the modification available, perhaps separately, perhaps as
part of the ht2html. I dunno yet.

>There must be a better way to contribute in a way
>that doesn't just generate more work for Finn :)

The web pages are being commited to CVS in the htdocs module, so all
developers can update the pages. 

  http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/htdocs/?cvsroot=jython

(How to become a developer, you ask? That's not difficult. Suggest some
big or complicated patch, which none of the current developers will
spend their time commiting themselves. Use the patch manager on SF to
suggest your patch)

In time, we will perhaps get some hosting on Zope by the DC folks. That
should give us other options for maintaining a website.

regards,
finn

Re: [Jython-dev] Jython homepage

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

On Sun, 12 Nov 2000, Finn Bock wrote:

> Hi,
> 
> I have uploaded a set of webpages to:
> 
>    http://jython.sourceforge.net/
> 
> They are basicly the jpython pages but the name have changed and I have
> updated some of the information. Please give it a lookover. 
> 
> The platform page:
> 
>    http://jython.sourceforge.net/platform.html
> 
> is properly completely out-of-dated, but I need some hard
> information on
> what to say about all the non-windows platforms.

Non-windows platform info.

Linux 2.2.12 JDK's used with Jython.
-------------------------------------
Blackdown - Following blackdown versions have been used with
JPython+errata, and I'm assuming they function with jython.

http://www.blackdown.org/java-linux/ports.html
	1.3.0 ppc, i386  
	1.2.2 i386, ppc
	1.1.8 v3 ppc, i386



IBMJava Development Kits- These have been used with
JPython+errata, as well as jython with success. 

Note: unresolved installer problem

IBMJava jdk for linux 2-13
http://www.ibm.com/java/jdk/linux130

IBMJava jdk for linux 1.1.8
http://www.ibm.com/java/jdk/118/linux/

---------------------------------------------------
Solaris 2.8, SunOS 5.8
	All ok with:
	Sun jdk 1.1.8
	Sun jdk 1.2


> Report broken links, bad grammar and wrong spelling to me.

page=jython.sourceforege.net
re=Grammer correction, suggestion.

current= "Note that these pages does not correctly reflect the
current state of Jython. Most importantly, there does not yet
exists a downloadable version." 

suggested update= "Note: A downloadable version of Jython is
not yet available. <br><br>
The current state of Jython development is not accurately
represented in these pages.  Consider joining the Jython
mailing lists for more current information. <br>
<font size=-1> last updated 11/12/2000 </font>"


page=License page.
re=Can this be updated so that the nav bar isn't lost?


Q- are these pages really generated as noted in their
comments?  There must be a better way to contribute in a way
that doesn't just generate more work for Finn :)

Ooops,
It appears that sourceforge is temporarily unavailable- so
I'll check more later.


-Robert

[Jython-dev] Jython homepage

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

Hi,

I have uploaded a set of webpages to:

   http://jython.sourceforge.net/

They are basicly the jpython pages but the name have changed and I have
updated some of the information. Please give it a lookover. 

The platform page:

   http://jython.sourceforge.net/platform.html

is properly completely out-of-dated, but I need some hard information on
what to say about all the non-windows platforms.

Report broken links, bad grammar and wrong spelling to me.

regards,
finn

Re: [Jython-dev] work in progress: rel files ctr

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

On Thu, 9 Nov 2000 16:09:53 +0100 (MET), you wrote:

>... null seems to do the right job, at least
>with java2.

Also for MS jview 5.00.3229 and jdk1.1.7a

regards,
finn

Re: [Jython-dev] work in progress: rel files ctr

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

Sorry, I have tried it concretely.

The java 1.2 doc is confused too.

You [Finn] are right, null seems to do the right job, at least
with java2.

regards, Samuele.

Re: [Jython-dev] work in progress: rel files ctr

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

Hi.

Really just a detail.
[Finn Bock]
> I think it would be better to let the File() ctor create and handle the
> aspect of relative files. I.e. 
> 
>             if (dirName.length() == 0)
>                 dirName = null;
>             File dir = new File(dirName, name);
> 
> It is not well defined, what will happen if the dirName == "", but a
> null directory value will create a relative file.

Reading the sun docs:

http://java.sun.com/j2se/1.3/docs/api/java/io/File.html#File(java.lang.String, 
java.lang.String)

The contrary seems true, at least for java2. So that "" is the right choice
to get a "rel" dir.

But my fear is really for java1.1 and the Macs.
The old sun jdk1.1 doc is mostly unclear.

regards, Samuele

Re: [Jython-dev] work in progress

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

[Samuele Pedroni]

>Basically I have finished the tentative (open for discussion) patch/rewr.
>for loading precedence and merging the PyJava*Package classes.
>(I have setup also some hooks in PackageManager impl. and PyJavaPackage
>for the future load sets).
>I have to test it and then it will appear here.
>
>I have some questions on assumptions I have made:
>
>(I) For use as a 1st arg to a two args File ctr, an empty string is always
>explicitly expanded in jython codebase, sometimes with
> if( dir.equals("") ) dir=".";
>sometimes with
> if( dir.equals("") ) dir=<the value of System.getProperty("user.dir")>;
>The two methods should be aquivalent, does someone know how could they
>be different? which one should be preferred?
>(e.g. are there problems with the first method on a Mac jvm?)

I think it would be better to let the File() ctor create and handle the
aspect of relative files. I.e. 

            if (dirName.length() == 0)
                dirName = null;
            File dir = new File(dirName, name);

It is not well defined, what will happen if the dirName == "", but a
null directory value will create a relative file.
Clearly both imp.loadFromPath and BytecodeLoader.open should use the
same algorithm. That they doesn't just show that noone have had the Big
Picture.

>(II) a) I have fixed (I hope) the relative import in package modules bug
>(runtime side, not jythonc yet),
>I had to rewrite the three args imp.importName was code dealt only with
>relative module import and not packages and was buggy wrt. to the top flag,
>
>the runtime enforce and the old code assumed that if x.y.z is a key in 
>sys.modules (x.y.z loaded) also any subseq (e.g. x,x.y) will be present as a key 
>in sys.modules.
>I have used that assumption too, and took care that the runtime enforce its
>validity. Any one sees problem with that?

No. From my understanding that is what sys.modules should contain.

>b) Is the following correct for CPython?, I have tryed to enforce it also
>in jython:
>
>p0,p1 are py packages
>
>if I do the following in a p1.a module:
>
> import sys
> import p0.a.b.x
> from p0.a.b.y import val
>
>the keys p1.sys and p1.p0 will be added to sys.modules with value None.
>But no key of the form p1.p0.a... etc. (clearly the plain keys p0... and sys,
>binding to the real modules will be added too).

That is indeed what CPython does. From the source, the None values
appears to some kind of optimizations, inserted just to show that these
module names does not exists. But it is difficult to be sure, the
dotted-import source code in CPython is not much better than Jython's.

regards,
finn

AW: AW: [Jython-dev] work in progress

[Schmidmeier, A. <Arn...@si...>]

> -----Ursprüngliche Nachricht-----
> Von:	Samuele Pedroni [SMTP:pe...@in...]
> Gesendet am:	Donnerstag, 9. November 2000 13:55
> An:	jyt...@li...
> Betreff:	Re: AW: [Jython-dev] work in progress
> 
> Hi.
> 
> [Schmidmeier, Arno]
> >  Yes they can be different. e.g. py passing
> > -Duser.dir=~/something on the commandline of the java VM.
> > 	I do not know which should be preferred, but my feeling says me that
> > "" eqalsto System.getProperty("user.dir")should be preffered.
> > 	However there might be a problem is the access to System.getProperty
> > is restricted or if this property is not defined.
> > 	I suggest therefore something like:
> > 
> > 	String FileName=null;
> > 	try{
> > 		FileName=System.getProperty("user.dir",null);
> > 	}catch(SecurityException sec){}
> > 	if (FileName==null)
> > 		FileName=".";
> > 	...
> I should admit I had missed these aspects. In any case the expansion
> happen when interpreting classpath and sys.path, so "." is preferable.
	[Schmidmeier, Arno]  I see here a problem with a bug in old versions
of JPython.
	I do not know if it is fixed. It is pretty likely that . is on the
classpath and also on sys.path.
	Older Versions of Jpython require a totally distinct classpath and
sys.path.
	I am a bit scarry, only if this bug still exist, 
	that you might add unwanted . to the classpath or sys.path.
	If this bug is fixed . is ok for me.

> But I really worry about what happens on a Mac?
> Unfortunately I have no access to such a machine and its jvms.
> 
>  	[Schmidmeier, Arno]  
> > 	I do not understand this topic fully, I want to ask is following
> > scenario possible:
> > 	I have a java-package X with classes a and b.
> > 	on the classpath (sys or jython) there are two distinct entries
> > j1.jar and j2.jar. 
> > 	j1.jar contains a and j2.jar contains b. Is this possible?
> > 	Same for .py filesand directories.
> 
> The semantics for py modules will remain as in python, if one not plays
> with 
> __path__ a py packages span over just one directory and its subdirs.
> sys.path can contain only dirs (an extension for allowing zips and jars
> should be not too difficult but it depends on what happens on CPython side
> and for the moment I like to see what happen with the patch and get rid of
> old and (hopefully few) new bugs, extending things should be easier
> with a clean (so I hope) codebase.
	[Schmidmeier, Arno]  I agree, extending things is much easier with a
clean codebase.
	I vote for cleaning up first, then adding features.
> The support for relative imports inside py pkgs should work as in CPython.
> This should still be fixed in jythonc.
> Concerning java with the patch:
> * classpath is virtually extended with sys.path
> classpath take over sys.path.
> * py pkgs take over java pkgs, but the java classes in the shadowed pkg
>  can be accessed through the py package
	[Schmidmeier, Arno]  I am a bit scary about this. Will following
scenario work, with this design and implementation:
	I subclass a Java-Interface with Jython and create an instance a. 
	(Jython needs to load the Java Interface), it is currently not in
the Java VM. (instance of java.lang.Class called IJP
	A second Java Thread needs the class for the Java-Interface so it
query the Java-Classloader after the interface, the classloader returns IJ.
	Jython passes A to a Java-Object which was loaded by the
Java-Classloader.
	Now is IJP==IJ?

> * dir and from import * for a java package now should really consider
> the union of everything that's is in the dirs/jar on classpath and in the
> dirs on sys.path.
> 
> regards, Samuele
> 
> 
	[Schmidmeier, Arno]  
	regards
		Arno 

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

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

Hi.

[Schmidmeier, Arno]
>  Yes they can be different. e.g. py passing
> -Duser.dir=~/something on the commandline of the java VM.
> 	I do not know which should be preferred, but my feeling says me that
> "" eqalsto System.getProperty("user.dir")should be preffered.
> 	However there might be a problem is the access to System.getProperty
> is restricted or if this property is not defined.
> 	I suggest therefore something like:
> 
> 	String FileName=null;
> 	try{
> 		FileName=System.getProperty("user.dir",null);
> 	}catch(SecurityException sec){}
> 	if (FileName==null)
> 		FileName=".";
> 	...
I should admit I had missed these aspects. In any case the expansion
happen when interpreting classpath and sys.path, so "." is preferable.
But I really worry about what happens on a Mac?
Unfortunately I have no access to such a machine and its jvms.

 	[Schmidmeier, Arno]  
> 	I do not understand this topic fully, I want to ask is following
> scenario possible:
> 	I have a java-package X with classes a and b.
> 	on the classpath (sys or jython) there are two distinct entries
> j1.jar and j2.jar. 
> 	j1.jar contains a and j2.jar contains b. Is this possible?
> 	Same for .py filesand directories.

The semantics for py modules will remain as in python, if one not plays with 
__path__ a py packages span over just one directory and its subdirs.
sys.path can contain only dirs (an extension for allowing zips and jars
should be not too difficult but it depends on what happens on CPython side
and for the moment I like to see what happen with the patch and get rid of
old and (hopefully few) new bugs, extending things should be easier
with a clean (so I hope) codebase.
The support for relative imports inside py pkgs should work as in CPython.
This should still be fixed in jythonc.
Concerning java with the patch:
* classpath is virtually extended with sys.path
classpath take over sys.path.
* py pkgs take over java pkgs, but the java classes in the shadowed pkg
 can be accessed through the py package
* dir and from import * for a java package now should really consider
the union of everything that's is in the dirs/jar on classpath and in the
dirs on sys.path.

regards, Samuele

[Jython-dev] work in progress

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

Hi.

Basically I have finished the tentative (open for discussion) patch/rewr.
for loading precedence and merging the PyJava*Package classes.
(I have setup also some hooks in PackageManager impl. and PyJavaPackage
for the future load sets).
I have to test it and then it will appear here.

I have some questions on assumptions I have made:

(I) For use as a 1st arg to a two args File ctr, an empty string is always
explicitly expanded in jython codebase, sometimes with
 if( dir.equals("") ) dir=".";
sometimes with
 if( dir.equals("") ) dir=<the value of System.getProperty("user.dir")>;
The two methods should be aquivalent, does someone know how could they
be different? which one should be preferred?
(e.g. are there problems with the first method on a Mac jvm?)

(II) a) I have fixed (I hope) the relative import in package modules bug
(runtime side, not jythonc yet),
I had to rewrite the three args imp.importName was code dealt only with
relative module import and not packages and was buggy wrt. to the top flag,

the runtime enforce and the old code assumed that if x.y.z is a key in 
sys.modules (x.y.z loaded) also any subseq (e.g. x,x.y) will be present as a key 
in sys.modules.
I have used that assumption too, and took care that the runtime enforce its
validity. Any one sees problem with that?

b) Is the following correct for CPython?, I have tryed to enforce it also
in jython:

p0,p1 are py packages

if I do the following in a p1.a module:

 import sys
 import p0.a.b.x
 from p0.a.b.y import val

the keys p1.sys and p1.p0 will be added to sys.modules with value None.
But no key of the form p1.p0.a... etc. (clearly the plain keys p0... and sys,
binding to the real modules will be added too).


regards, Samuele

[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