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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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