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

Re: [Jython-dev] __builtins__ support (with patch)

[Randy J. Y. <ry...@we...>]

Samuele,

The primary reason is that I have some legacy code that uses 
__builtins__ that I would rather not
have to rewrite. It's an application maintain by another party and I 
don't want to have to continually
sync with their copy.

In addition, there are some neat things you can do, like dynamically 
being able to re-define the behavior of builtin functions and add new 
builtins...

The patch seems to be sound, and I don't understand why it's hitting 
those null frames in the current CVS, so any ideas would be appreciated.

-Randy
Web Elite
ry...@we...

Samuele Pedroni wrote:

>>All,
>>
>>After seeing that the org.python.core.__builtin__ module behaves quite 
>>like the cPython __builtins__ module I put together the following patch 
>>to provide __builtins__ just like cPython.
>>
>Why do you find that important?
>
>regards, Samuele Pedroni.
>

Re: [Jython-dev] __builtins__ support (with patch)

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

> All,
> 
> After seeing that the org.python.core.__builtin__ module behaves quite 
> like the cPython __builtins__ module I put together the following patch 
> to provide __builtins__ just like cPython.
> 
Why do you find that important?

regards, Samuele Pedroni.

Re: [Jython-dev] Pickling for PyMetaClass

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

Hi,

> 
>     We're working on a project involving ExtensionClasses and have written
> some code to that end. (The project is open source, but we haven't
> "announced" it yet, because we still need to build up some support
> infrastructure.)
> 
>     In order to pickle an ExtensionClass PyMetaClass, I had a couple of
> changes...
> 
> $ diff PyMetaClass.java ~/jython-20010719/org/python/core/PyMetaClass.java
> 5d4
> <     public PyObject __basicnew__();
> 
> 
> $ diff cPickle.java ~/jython-20010719/org/python/modules/cPickle.java
> 996c996
> <             else if (object instanceof PyClass)
> ---
> >             else if (cls == ClassType)
> 1821,1824c1821
> <                 if (klass instanceof PyMetaClass)
> <                     value = ((PyMetaClass) klass).__basicnew__();
> <                 else
> <                     value = new PyInstance((PyClass)klass);
> ---
> >                 value = new PyInstance((PyClass)klass);
> 
> Basically, this creates a requirement for a __basicnew__ method in a
> PyMetaClass. I'm not sure if there would be a cleaner way to designate what
> kind of instance object should be created. This seems like a pretty
> straightforward interface.
From empty to non-empty is universe creation <wink>

Seriously, up now I have had no time to make up my mind on this 

a bit of patience ... 

regards, Samuele Pedroni.

[Jython-dev] __builtins__ support (with patch)

[Randy J. Y. <ry...@we...>]

All,

After seeing that the org.python.core.__builtin__ module behaves quite 
like the cPython __builtins__ module I put together the following patch 
to provide __builtins__ just like cPython.

There's a problem though... This patch was orginally application to the 
nightly snapshot on 20010611. Against this snapshot everything works 
fine (at least for all of the tests I've thrown at it). However, against 
a more recent nightly (20010724) it fails. I've looked at it a little 
and seen this:

The patch calls __builtin__.__import__ to import the __builtin__ module. 
In the latest nightly this returns a null value.
In __builtin__.__import__ an early check is performed on Py.getFrame() 
and a null is returned if the frame is null. This is what is happening 
here. Inserting a debug line tells me that in 20010611 the frame is 
*never* null when __import__ is called, but in 20010724 the frame is 
null right before this problem occurs.

I'm going to try tonight's nightly to see if this is a transient 
problem, but I wanted to throw this patch out there in case anyone finds 
it useful...

-Randy Yarger
Web Elite
ry...@we...

diff -rw jython-20010611/org/python/core/PyModule.java 
jython-20010619/org/python/core/PyModule.java
15,19d14
<
<       if ( name.equals("__main__") ) {
<           __dict__.__setitem__("__builtins__", 
__builtin__.__import__("__builtin__") );
<       } else if (! name.equals("__builtin__") ) {
<           __dict__.__setitem__("__builtins__", 
((PyModule)__builtin__.__import__("__builtin__")).__dict__ );
21d15
<     }

Re: [Jython-dev] zip files on sys.path

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

[Finn]
> 
> >I have checked the code of your 2nd patch  (but yet not tried it).
> >The patch is neat, but here are some comments:
> >
> >> The magic string -> SyspathArchive works on all paths of this form, but
> >> it will cause the archive to be opened each such a string is found on
> >> sys.path. Hardly a problem I think.
> 
> >I don't know if that's a problem or not, but in case a central
> >cache with a (incredible under java) simple ref count logic can do the job.
> >I propose ref counting because weak-refs work only under Java2.
> 
> We can add it later if it turns out to be a problem.
OK.
 
> >The logic for detecting a jar!relpath entry seems a bit weak, if the user
> >have paths around containing a !. Insane, of course, but ...
> 
> It'll happen at some point. I'll add an additional test on whether the
> full string is a directory and skip the new zip logic if it is.
> 
> >Maybe SysArchives should have an archive_close method (in case), closing
> >the zip or playing well with the central cache.
> 
> Yeah but the semantic then depends on the implementation. If some code
> in package calls archive_close() on the SyspathArchive in its __path__
> should further imports from the SyspathArchive on sys.path still
> succeed?
Yes with a re-open logic, or no raising a specific exception:
	encountered closed SyspathArchive,
The second option seems more meaningful to me.

A special case is sys.path and java class loading:
there if you remove an archive from sys.path after you have loaded
some classes, maybe you can get an error later, because the loading
of some referenced classes can fail.
It depends on when resolve is called.
I don't remember the details.

> >The final point: imp has always been a bit messy (I always wanted to
> >polish it a bit ..), and now loadFromZipFile adds another amount of code
> >duplication wrt loadFromPath ...
> >so I would prefer things factored in another way...
> >in case I can do that.
> 
> I agree, but lets do the refactoring after 2.1 final and before 2.2a1. 
> 
Yup.

Samuele.

Re: [Jython-dev] zip files on sys.path

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

[Samuele]

>I have checked the code of your 2nd patch  (but yet not tried it).
>The patch is neat, but here are some comments:
>
>> The magic string -> SyspathArchive works on all paths of this form, but
>> it will cause the archive to be opened each such a string is found on
>> sys.path. Hardly a problem I think.

>I don't know if that's a problem or not, but in case a central
>cache with a (incredible under java) simple ref count logic can do the job.
>I propose ref counting because weak-refs work only under Java2.

We can add it later if it turns out to be a problem.

>The logic for detecting a jar!relpath entry seems a bit weak, if the user
>have paths around containing a !. Insane, of course, but ...

It'll happen at some point. I'll add an additional test on whether the
full string is a directory and skip the new zip logic if it is.

>Maybe SysArchives should have an archive_close method (in case), closing
>the zip or playing well with the central cache.

Yeah but the semantic then depends on the implementation. If some code
in package calls archive_close() on the SyspathArchive in its __path__
should further imports from the SyspathArchive on sys.path still
succeed?

I can see its use but the semantics of such a close method isn't
entirely clear to me. That is probably a strong sign that the
implementation isn't clear either.

>The final point: imp has always been a bit messy (I always wanted to
>polish it a bit ..), and now loadFromZipFile adds another amount of code
>duplication wrt loadFromPath ...
>so I would prefer things factored in another way...
>in case I can do that.

I agree, but lets do the refactoring after 2.1 final and before 2.2a1. 

regards,
finn

[Jython-dev] [ jython-Patches-442906 ] Console encoding.

[<no...@so...>]

Patches item #442906, was opened at 2001-07-19 14:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=442906&group_id=12867

Category: None
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Finn Bock (bckfnn)
Assigned to: Samuele Pedroni (pedronis)
Summary: Console encoding.

Initial Comment:
A patch that allow a different encoding used in the 
console.

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

>Comment By: Finn Bock (bckfnn)
Date: 2001-07-25 11:51

Message:
Logged In: YES 
user_id=4201

Commited today.

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

Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-25 07:01

Message:
Logged In: YES 
user_id=61408

2nd version checked and OK. -- sP

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

Comment By: Finn Bock (bckfnn)
Date: 2001-07-21 02:44

Message:
Logged In: YES 
user_id=4201

I committed a far better fix to the syntax error in bug 
#439688. As a result, the second version of this patch only 
deals with changing the console encoding.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=442906&group_id=12867

Re: [Jython-dev] how to use os.path?, renaming packages

[Ype K. <yk...@xs...>]

Finn,

>[Ype Kingma]
>
>>I investigated the problem of my previous post (below).
>>It appears that os.path.dirname() is confused when
>>using both backward and forward slashes, ...
>
>Could you show an example of this confusion? I think the results is far
>better than what I had feared:
>
>Jython 2.1a2 on java1.4.0-beta (JIT: null)
>Type "copyright", "credits" or "license" for more information.
>>>> import os
>>>> os.path.dirname('e:\\someDir\\packag/modul.py')
>'e:\\someDir\\packag'
>>>> os.path.dirname('e:\\someDir\\packag\\modul.py')
>'e:\\someDir\\packag'
>>>> os.path.dirname('e:\\someDir/packag/modul.py')
>'e:\\someDir\\packag'
>>>>

I'll give the answer in a day or two. I vaguely recall that output
of your first example was  'e:\\someDir', but real output is better.

<snip>
>
>>Finally another thing (21a1): I renamed the directory of a package,
>>and then changed all occurrences of the package name.
> >Then I found out that the compiled modules contain a reference
> >to the old package file name, even though they where loaded
> >using the new package name. The fix was to remove the class files.
>>Should this be added to the docs or is it a bug?
>
>I suppose it depends on the situation. Note that CPython will write the
>old packagename in stacktraces. Where is it you say the old package
>names?

Off the top of my head:
It's in the __filename__ attribute of the imported compiled module:
  sys.modules['modul'].__filename__

Thanks,
Ype

Re: [Jython-dev] Console encoding.

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

[Samuele]

>The patch (I have checked the 2nd version) is fine for me, it makes
>a sensible use of CompilerFlags. Just commit it.

Okay.

>Finn, have you an idea of why java fails to select a proper default
>enconding on Windows?

I think it works for me. Java selects 'Cp1252' which seems correct for
reading and writing files in my locale. It is only the console encoding
(cp850 or cp865 for danish) that java does not detect.

regards,
finn

[Jython-dev] Pickling for PyMetaClass

[Kevin D. <kda...@we...>]

    We're working on a project involving ExtensionClasses and have written
some code to that end. (The project is open source, but we haven't
"announced" it yet, because we still need to build up some support
infrastructure.)

    In order to pickle an ExtensionClass PyMetaClass, I had a couple of
changes...

$ diff PyMetaClass.java ~/jython-20010719/org/python/core/PyMetaClass.java
5d4
<     public PyObject __basicnew__();


$ diff cPickle.java ~/jython-20010719/org/python/modules/cPickle.java
996c996
<             else if (object instanceof PyClass)
---
>             else if (cls == ClassType)
1821,1824c1821
<                 if (klass instanceof PyMetaClass)
<                     value = ((PyMetaClass) klass).__basicnew__();
<                 else
<                     value = new PyInstance((PyClass)klass);
---
>                 value = new PyInstance((PyClass)klass);

Basically, this creates a requirement for a __basicnew__ method in a
PyMetaClass. I'm not sure if there would be a cleaner way to designate what
kind of instance object should be created. This seems like a pretty
straightforward interface.

Kevin

Re: [Jython-dev] zip files on sys.path

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

Hi,

I have checked the code of your 2nd patch  (but yet not tried it).
The patch is neat, but here are some comments:

> The magic string -> SyspathArchive works on all paths of this form, but
> it will cause the archive to be opened each such a string is found on
> sys.path. Hardly a problem I think.
I don't know if that's a problem or not, but in case a central
cache with a (incredible under java) simple ref count logic can do the job.
I propose ref counting because weak-refs work only under Java2.

The logic for detecting a jar!relpath entry seems a bit weak, if the user
have paths around containing a !. Insane, of course, but ...

Maybe SysArchives should have an archive_close method (in case), closing
the zip or playing well with the central cache.

The final point: imp has always been a bit messy (I always wanted to
polish it a bit ..), and now loadFromZipFile adds another amount of code
duplication wrt loadFromPath ...
so I would prefer things factored in another way...
in case I can do that.

Samuele.

[Jython-dev] [ jython-Patches-442906 ] Console encoding.

[<no...@so...>]

Patches item #442906, was opened at 2001-07-19 14:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=442906&group_id=12867

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Finn Bock (bckfnn)
Assigned to: Samuele Pedroni (pedronis)
Summary: Console encoding.

Initial Comment:
A patch that allow a different encoding used in the 
console.

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

>Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-25 07:01

Message:
Logged In: YES 
user_id=61408

2nd version checked and OK. -- sP

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

Comment By: Finn Bock (bckfnn)
Date: 2001-07-21 02:44

Message:
Logged In: YES 
user_id=4201

I committed a far better fix to the syntax error in bug 
#439688. As a result, the second version of this patch only 
deals with changing the console encoding.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=442906&group_id=12867

Re: [Jython-dev] Console encoding.

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

Hi.

The patch (I have checked the 2nd version) is fine for me, it makes
a sensible use of CompilerFlags. Just commit it.

Finn, have you an idea of why java fails to select a proper default
enconding on Windows?

Samuele

Re: [Jython-dev] new, trouble w/ simple applet NB

[<mt...@ho...>]

I just realized it is important to mention that I am using netscape 4.72
(is there a better choice on Linux for Java stuff?)

(Sorry for causing too much traffic).
M

On 24 Jul, To: jyt...@li... wrote:
> Hi,
> 
> I am teaching a simple introductory course on programming. I am using
> Python and am interested in introducing at the end for interest sake the
> ability to create simple little programs running inside a browser.
> 
> I am a bit clueless about Java.
> 
> I have CLASSPATH set to:
> 
> [mt@galois applet]$ plecho $CLASSPATH
> /home/mt/external/jython-2.1a1/jython.jar
> .
> ./jpywork
> /home/mt/external/jython-2.1a1/Tools/jythonc
> /home/mt/external/jython-2.1a1
> /home/mt/external/jython-2.1a1/Lib
> 
> I have the following HelloWorld.py file:
> 
> from java.applet import Applet
> 
> class HelloWorld(Applet):
>     def paint(self, g):
>         g.drawString("Hello from Jython!", 20, 30)
> 
> Running jythonc -J deprecation HelloWorld.py
> produces a class file with 9 deprecated API warnings.
> 
> I have the following html file:
> 
> <html>
> <body>
> <center>
> <applet code="HelloWorld.class"
>     width = 500
>     height = 105>
> </applet>
> </center>
> </body>
> </html>
> 
> The environment that netscape has does contain the same CLASSPATH
> variable (this is required right?).
> 
> Here is the java console output:
> 
> # Applet exception: exception: java.lang.NullPointerException: trying to call makeJavaPackage(Ljava/lang/String;Ljava/lang/Str
> java.lang.NullPointerException: trying to call makeJavaPackage(Ljava/lang/String;Ljava/lang/Str
>   at org.python.core.PySystemState.add_package(PySystemState.java:504)
>   at org.python.core.Py.initProperties(Py.java:701)
>   at org.python.core.Py.initProxy(Py.java:719)
> * at HelloWorld.__initProxy__(HelloWorld.java:192)
>   at HelloWorld.<init>(HelloWorld.java:170)
>   at netscape.applet.DerivedAppletFrame$LoadAppletEvent.dispatch(DerivedAppletFrame.java:456)
>   at java.awt.EventDispatchThread$EventPump.dispatchEvents(EventDispatchThread.java:81)
>   at java.awt.EventDispatchThread.run(EventDispatchThread.java:135)
>   at netscape.applet.DerivedAppletFrame$AppletEventDispatchThread.run(DerivedAppletFrame.java:911)
> 
> What the hell does this mean????
> 
> I am using Jython 2.1a1 and JDK (from Sun) 1.3.1
> 
> For interest sake here are the warning from jythonc:
> 
> Compiling .java to .class...
> Compiling with args: ['/usr/local/jdk1.3.1/bin/javac', '-deprecation', '-classpa
> th', '"/home/mt/external/jython-2.1a1/jython.jar:/home/mt/external/jython-2.1a1/
> jython.jar:.:./jpywork:/home/mt/external/jython-2.1a1/Tools/jythonc:/home/mt/ext
> ernal/jython-2.1a1:/home/mt/external/jython-2.1a1/Lib:./jpywork::/home/mt/extern
> al/jython-2.1a1/Tools/jythonc:/home/mt/external/jython-2.1a1/Demo/applet/.:/home
> /mt/external/jython-2.1a1/Lib"', './jpywork/HelloWorld.java']
> 0  /home/mt/external/jython-2.1a1/org/python/core/PyString.java:649: warning: getBytes(int,int,byte[],int) in java.lang.String has been deprecated
>         string.getBytes(0, string.length(), buf, 0);
>               ^
> /home/mt/external/jython-2.1a1/org/python/core/PyFile.java:65: warning: getBytes(int,int,byte[],int) in java.lang.String has been deprecated
>                 s.getBytes(0, s.length(), buf, 0);
>                  ^
> /home/mt/external/jython-2.1a1/org/python/core/PyFile.java:74: warning: String(byte[],int,int,int) in java.lang.String has been deprecated
>                 return new String(buf, 0, offset, len);
>                        ^
> /home/mt/external/jython-2.1a1/org/python/core/PyFile.java:109: warning: String(byte[],int,int,int) in java.lang.String has been deprecated
>             return new String(buf, 0, 0, read);
>                    ^
> /home/mt/external/jython-2.1a1/org/python/core/__builtin__.java:212: warning: java.io.StringBufferInputStream in java.io has been deprecated
>         return Py.compile(new java.io.StringBufferInputStream(data+"\n\n"),
>                                      ^
> /home/mt/external/jython-2.1a1/org/python/core/PyArray.java:139: warning: String(byte[],int) in java.lang.String has been deprecated
>             return new String((byte[])data, 0);
>                    ^
> /home/mt/external/jython-2.1a1/org/python/core/parser.java:70: warning: java.io.StringBufferInputStream in java.io has been deprecated
>         return parse(new StringBufferInputStream(string), kind, "<string>");
>                          ^
> /home/mt/external/jython-2.1a1/org/python/core/parser.java:137: warning: java.io.StringBufferInputStream in java.io has been deprecated
>             node = parse(new StringBufferInputStream(string), kind, filename);
>                              ^
> /home/mt/external/jython-2.1a1/org/python/core/parser.java:143: warning: java.io.StringBufferInputStream in java.io has been deprecated
>                 node = parse(new StringBufferInputStream(string+"\n"),
>                                  ^
> 9 warnings
> 
> Anybody have a clue as to what I am doing wrong?  I have tried copying
> the HelloWorld.class all sorts of different places.  I have tried
> calling the .class file in the html file different names like HelloWorld
> or jpywork/HelloWorld.class jpywork.HelloWorld - pretty much every
> conceivable combo.
> 
> This applet is working for me at http://www.jython.org/applets the
> source of the html there is exactly what I have.
> 
> I don't know what I am doing wrong.
> 
> Thanks for any help.
> Cheers,
> Mark
> 
> 
> 
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/lists/listinfo/jython-dev

[Jython-dev] new, trouble w/ simple applet

[<mt...@ho...>]

Hi,

I am teaching a simple introductory course on programming. I am using
Python and am interested in introducing at the end for interest sake the
ability to create simple little programs running inside a browser.

I am a bit clueless about Java.

I have CLASSPATH set to:

[mt@galois applet]$ plecho $CLASSPATH
/home/mt/external/jython-2.1a1/jython.jar
.
./jpywork
/home/mt/external/jython-2.1a1/Tools/jythonc
/home/mt/external/jython-2.1a1
/home/mt/external/jython-2.1a1/Lib

I have the following HelloWorld.py file:

from java.applet import Applet

class HelloWorld(Applet):
    def paint(self, g):
        g.drawString("Hello from Jython!", 20, 30)

Running jythonc -J deprecation HelloWorld.py
produces a class file with 9 deprecated API warnings.

I have the following html file:

<html>
<body>
<center>
<applet code="HelloWorld.class"
    width = 500
    height = 105>
</applet>
</center>
</body>
</html>

The environment that netscape has does contain the same CLASSPATH
variable (this is required right?).

Here is the java console output:

# Applet exception: exception: java.lang.NullPointerException: trying to call makeJavaPackage(Ljava/lang/String;Ljava/lang/Str
java.lang.NullPointerException: trying to call makeJavaPackage(Ljava/lang/String;Ljava/lang/Str
  at org.python.core.PySystemState.add_package(PySystemState.java:504)
  at org.python.core.Py.initProperties(Py.java:701)
  at org.python.core.Py.initProxy(Py.java:719)
* at HelloWorld.__initProxy__(HelloWorld.java:192)
  at HelloWorld.<init>(HelloWorld.java:170)
  at netscape.applet.DerivedAppletFrame$LoadAppletEvent.dispatch(DerivedAppletFrame.java:456)
  at java.awt.EventDispatchThread$EventPump.dispatchEvents(EventDispatchThread.java:81)
  at java.awt.EventDispatchThread.run(EventDispatchThread.java:135)
  at netscape.applet.DerivedAppletFrame$AppletEventDispatchThread.run(DerivedAppletFrame.java:911)

What the hell does this mean????

I am using Jython 2.1a1 and JDK (from Sun) 1.3.1

For interest sake here are the warning from jythonc:

Compiling .java to .class...
Compiling with args: ['/usr/local/jdk1.3.1/bin/javac', '-deprecation', '-classpa
th', '"/home/mt/external/jython-2.1a1/jython.jar:/home/mt/external/jython-2.1a1/
jython.jar:.:./jpywork:/home/mt/external/jython-2.1a1/Tools/jythonc:/home/mt/ext
ernal/jython-2.1a1:/home/mt/external/jython-2.1a1/Lib:./jpywork::/home/mt/extern
al/jython-2.1a1/Tools/jythonc:/home/mt/external/jython-2.1a1/Demo/applet/.:/home
/mt/external/jython-2.1a1/Lib"', './jpywork/HelloWorld.java']
0  /home/mt/external/jython-2.1a1/org/python/core/PyString.java:649: warning: getBytes(int,int,byte[],int) in java.lang.String has been deprecated
        string.getBytes(0, string.length(), buf, 0);
              ^
/home/mt/external/jython-2.1a1/org/python/core/PyFile.java:65: warning: getBytes(int,int,byte[],int) in java.lang.String has been deprecated
                s.getBytes(0, s.length(), buf, 0);
                 ^
/home/mt/external/jython-2.1a1/org/python/core/PyFile.java:74: warning: String(byte[],int,int,int) in java.lang.String has been deprecated
                return new String(buf, 0, offset, len);
                       ^
/home/mt/external/jython-2.1a1/org/python/core/PyFile.java:109: warning: String(byte[],int,int,int) in java.lang.String has been deprecated
            return new String(buf, 0, 0, read);
                   ^
/home/mt/external/jython-2.1a1/org/python/core/__builtin__.java:212: warning: java.io.StringBufferInputStream in java.io has been deprecated
        return Py.compile(new java.io.StringBufferInputStream(data+"\n\n"),
                                     ^
/home/mt/external/jython-2.1a1/org/python/core/PyArray.java:139: warning: String(byte[],int) in java.lang.String has been deprecated
            return new String((byte[])data, 0);
                   ^
/home/mt/external/jython-2.1a1/org/python/core/parser.java:70: warning: java.io.StringBufferInputStream in java.io has been deprecated
        return parse(new StringBufferInputStream(string), kind, "<string>");
                         ^
/home/mt/external/jython-2.1a1/org/python/core/parser.java:137: warning: java.io.StringBufferInputStream in java.io has been deprecated
            node = parse(new StringBufferInputStream(string), kind, filename);
                             ^
/home/mt/external/jython-2.1a1/org/python/core/parser.java:143: warning: java.io.StringBufferInputStream in java.io has been deprecated
                node = parse(new StringBufferInputStream(string+"\n"),
                                 ^
9 warnings

Anybody have a clue as to what I am doing wrong?  I have tried copying
the HelloWorld.class all sorts of different places.  I have tried
calling the .class file in the html file different names like HelloWorld
or jpywork/HelloWorld.class jpywork.HelloWorld - pretty much every
conceivable combo.

This applet is working for me at http://www.jython.org/applets the
source of the html there is exactly what I have.

I don't know what I am doing wrong.

Thanks for any help.
Cheers,
Mark

Re: [Jython-dev] how to use os.path?, renaming packages

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

[Ype Kingma]

>I investigated the problem of my previous post (below).
>It appears that os.path.dirname() is confused when
>using both backward and forward slashes, ...

Could you show an example of this confusion? I think the results is far
better than what I had feared:

Jython 2.1a2 on java1.4.0-beta (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.dirname('e:\\someDir\\packag/modul.py')
'e:\\someDir\\packag'
>>> os.path.dirname('e:\\someDir\\packag\\modul.py')
'e:\\someDir\\packag'
>>> os.path.dirname('e:\\someDir/packag/modul.py')
'e:\\someDir\\packag'
>>>


>in the directory of the main module not being on sys.path,
>(through my own code) resulting the import failure reported.
>Also os.path.normcase() and os.path.normpath() don't seem
>to be doing much (21a2, 1.1.8, OS2), 

I think normcase a hard to do correctly on java. We could perhaps
improve the situation for a huge majority of users by testing for some
common case-ignoring OS'es. Windows and OS/2 spring to mind. Any others?

normpath() was missing a replace path.replace("/", sep) when sep is '\'
and I have added that. A part from that normpath seems to work
correctly. 

>so I added my own
>normPath() function doing lower(), replacing backward by forward
>slashes and replacing multiple slashes by a single one.
>(It doesn't replace \.\ by \, as which is sometimes needed
>for the filenames of imported modules.)
>
>I had a look at the various os.path implementations, and
>the NT one seems quite close to what is needed under OS2.
>However, I could not find where os.path is defined and
>whether something else than javapath can be used in Jython.
>
>In Java path names are system dependent, so it might be
>worthwhile to have all os.path implementations available
>in jython, together with some indication of the underlying
>OS, so the program can decide for itself how to treat pathnames.
>
>Or is this already possible in Jython?

Only with something like jnios.

>Finally another thing (21a1): I renamed the directory of a package,
>and then changed all occurrences of the package name.
>Then I found out that the compiled modules contain a reference
>to the old package file name, even though they where loaded
>using the new package name. The fix was to remove the class files.
>Should this be added to the docs or is it a bug?

I suppose it depends on the situation. Note that CPython will write the
old packagename in stacktraces. Where is it you say the old package
names?

regards,
finn

Re: [Jython-dev] how to use os.path?, renaming packages

[Ype K. <yk...@xs...>]

Finn,

I investigated the problem of my previous post (below).
It appears that os.path.dirname() is confused when
using both backward and forward slashes, resulting
in the directory of the main module not being on sys.path,
(through my own code) resulting the import failure reported.
Also os.path.normcase() and os.path.normpath() don't seem
to be doing much (21a2, 1.1.8, OS2), so I added my own
normPath() function doing lower(), replacing backward by forward
slashes and replacing multiple slashes by a single one.
(It doesn't replace \.\ by \, as which is sometimes needed
for the filenames of imported modules.)

I had a look at the various os.path implementations, and
the NT one seems quite close to what is needed under OS2.
However, I could not find where os.path is defined and
whether something else than javapath can be used in Jython.

In Java path names are system dependent, so it might be
worthwhile to have all os.path implementations available
in jython, together with some indication of the underlying
OS, so the program can decide for itself how to treat pathnames.

Or is this already possible in Jython?

Finally another thing (21a1): I renamed the directory of a package,
and then changed all occurrences of the package name.
Then I found out that the compiled modules contain a reference
to the old package file name, even though they where loaded
using the new package name. The fix was to remove the class files.
Should this be added to the docs or is it a bug?

Regards,
Ype


From previous post:

<snip>
A while ago (21a1, 1.1.8, OS2) I noticed that after a succesful:

  execfile('e:\\someDir\\packag/modul.py')

the following failed:

  from packag import modul

even though someDir is on sys.path.
However, the import would succeed after:

  execfile('e:\\someDir\\package\\modul.py')

(Note the backslash before modul.py)
<snip>

[Jython-dev] jythonc compile error in jython 2.1a2 (may be error)

[syKim <re...@ne...>]

hello.

I'm trying applet program..

my applet program use inner class extending & method overriding

sample code :
---------------------------------------------------------------
class TestEditorKit(HTMLEditorKit):
        def getViewFactory(self):
            return self.TestFactory()

        class TestFactory(HTMLEditorKit.HTMLFactory):
            def create(self,e):
                o =
e.getAttributes().getAttribute(StyleConstants.NameAttribute)
                if o == HTML.Tag.INPUT:
                    return html_event.TestFormView(e)
                return HTMLEditorKit.HTMLFactory.create(self,e)

    class TestFormView(FormView):
    	def __init__(self,e):
    	    FormView.__init__(self,e)

    	def test(self):
            print 'hello'

        def actionPerformed(self,e):
            self.test()

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

but, in 2.0 it's not work. (It doesn't make xxx$HTMLFactory)

then i try jython 2.1a2, although it makes xxx$HTMLFactory but it occur
error

then i test simply applet, it occur same error in every applet program.

the error message is :

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

Java Traceback:
 	at org.python.core.Py.JavaError(Py.java)
 	at org.python.core.Py.JavaError(Py.java)
 	at org.python.core.PyJavaClass.initialize(PyJavaClass.java)
 	at org.python.core.PyJavaClass.lookupGivingClass(PyJavaClass.java)
 	at org.python.core.PyClass.lookup(PyClass.java)
 	at org.python.core.PyJavaClass.__findattr__(PyJavaClass.java)
 	at org.python.core.PyObject.__getattr__(PyObject.java)
 	at org.python.core.Py.initExc(Py.java)
 	at org.python.core.Py.initClassExceptions(Py.java)
 	at org.python.core.PySystemState.initialize(PySystemState.java)
 	at org.python.core.Py.initProperties(Py.java)
 	at org.python.core.Py.initProxy(Py.java)
 	at html_event.__initProxy__(html_event.java:271)
 	at html_event.<init>(html_event.java:249)
 	at java.lang.Class.newInstance0(Native Method)
 	at java.lang.Class.newInstance(Unknown Source)
 	at sun.applet.AppletPanel.createApplet(Unknown Source)
 	at sun.plugin.AppletViewer.createApplet(Unknown Source)
 	at sun.applet.AppletPanel.runLoader(Unknown Source)
 	at sun.applet.AppletPanel.run(Unknown Source)
 	at java.lang.Thread.run(Unknown Source)
 Traceback (innermost last):   (no code object) at line 0
java.lang.NoClassDefFoundError: org/python/util/PyMetaClass
 	at org.python.core.Py.makeClass(Py.java)
 	at org.python.core.Py.makeClass(Py.java)
 	at org.python.core.exceptions.buildClass(exceptions.java)
 	at org.python.core.exceptions.classDictInit(exceptions.java)
 	at java.lang.reflect.Method.invoke(Native Method)
 	at org.python.core.PyJavaClass.initialize(PyJavaClass.java)
 	at org.python.core.PyJavaClass.lookupGivingClass(PyJavaClass.java)
 	at org.python.core.PyClass.lookup(PyClass.java)
 	at org.python.core.PyJavaClass.__findattr__(PyJavaClass.java)
 	at org.python.core.PyObject.__getattr__(PyObject.java)
 	at org.python.core.Py.initExc(Py.java)
 	at org.python.core.Py.initClassExceptions(Py.java)
 	at org.python.core.PySystemState.initialize(PySystemState.java)
 	at org.python.core.Py.initProperties(Py.java)
 	at org.python.core.Py.initProxy(Py.java)
 	at html_event.__initProxy__(html_event.java:271)
 	at html_event.<init>(html_event.java:249)
 	at java.lang.Class.newInstance0(Native Method)
 	at java.lang.Class.newInstance(Unknown Source)
 	at sun.applet.AppletPanel.createApplet(Unknown Source)
 	at sun.plugin.AppletViewer.createApplet(Unknown Source)
 	at sun.applet.AppletPanel.runLoader(Unknown Source)
 	at sun.applet.AppletPanel.run(Unknown Source)
 	at java.lang.Thread.run(Unknown Source)
  java.lang.NoClassDefFoundError: java.lang.NoClassDefFoundError:
org/python/util/PyMetaClass  	at org.python.core.Py.JavaError(Py.java) 	at
org.python.core.Py.JavaError(Py.java) 	at
org.python.core.PyJavaClass.initialize(PyJavaClass.java) 	at
org.python.core.PyJavaClass.lookupGivingClass(PyJavaClass.java) 	at
org.python.core.PyClass.lookup(PyClass.java) 	at
org.python.core.PyJavaClass.__findattr__(PyJavaClass.java) 	at
org.python.core.PyObject.__getattr__(PyObject.java) 	at
org.python.core.Py.initExc(Py.java) 	at
org.python.core.Py.initClassExceptions(Py.java) 	at
org.python.core.PySystemState.initialize(PySystemState.java) 	at
org.python.core.Py.initProperties(Py.java) 	at
org.python.core.Py.initProxy(Py.java) 	at
html_event.__initProxy__(html_event.java:271) 	at
html_event.<init>(html_event.java:249) 	at
java.lang.Class.newInstance0(Native Method) 	at
java.lang.Class.newInstance(Unknown Source) 	at
sun.applet.AppletPanel.createApplet(Unknown Source) 	at
sun.plugin.AppletViewer.createApplet(Unknown Source) 	at
sun.applet.AppletPanel.runLoader(Unknown Source) 	at
sun.applet.AppletPanel.run(Unknown Source) 	at java.lang.Thread.run(Unknown
Source)

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

i'm using jdk1.3.1 & jython 2.1a2 & windows 98 (i tested under windows2000)

it works well just using <jython excutionfilename>

but in case jythonc it's not work.

my method is :

jythonc -c -d -w . -j html_event.jar html_event.py

thanks

p.s : if you want my test source, i'll attatch it

Re: [Jython-dev] maybe bug in 2.1a1

[Ype K. <yk...@xs...>]

Finn,

>[Ype Kingma]
>
>>I solved the problem by removing all the $py.class files.
>
>Good.
>
>>After that I also noticed that 21a2 will not import *.PY modules (with
>>uppercase extension), so I had to change these to lower case.
>>Now 21a2 works beautifully.
>
>I think that is a bug. At least CPython only checks the case for the
>name part of the file. It doesn't check for the case of the extensions
>and I don't think Jython should either. I have comitted in a fix for it.

Having grown up in Unix I might tend to disagree about this being
a bug, but it is definitely not a language issue, so I'll end that rant.
I have to say, though, that allowing upper case it is consistent with
the python property of adapting to any environment.

>Thanks for reporting this.

My pleasure, especially after the fix. Here is some more:
A while ago (21a1, 1.1.8, OS2) I noticed that after a succesful:

  execfile('e:\\someDir\\packag/modul.py')

the following failed:

  from packag import modul

even though someDir is on sys.path.
However, the import would succeed after:

  execfile('e:\\someDir\\package\\modul.py')

(Note the backslash before modul.py)
I used this to test modul.py before importing it.
I thought this was somewhat weird because of the existence
of os.abspath() (name ok?) that provides a 'normalized'
form of any full file name.

If you want this behavior confirmed in 21a2 just
let me know. This one is so easy to work around that
I did not bother reporting it as a bug at the time.

Regards,
Ype

Re: [Jython-dev] bug in 2.1a2

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

[Ype Kingma]

>I solved the problem by removing all the $py.class files.

Good.

>After that I also noticed that 21a2 will not import *.PY modules (with
>uppercase extension), so I had to change these to lower case.
>Now 21a2 works beautifully.

I think that is a bug. At least CPython only checks the case for the
name part of the file. It doesn't check for the case of the extensions
and I don't think Jython should either. I have comitted in a fix for it.

Thanks for reporting this.

regards,
finn

Re: [Jython-dev] bug in 2.1a2

[Ype K. <yk...@xs...>]

Finn, Samuele,

I solved the problem by removing all the $py.class files.
After that I also noticed that 21a2 will not import *.PY modules (with
uppercase extension), so I had to change these to lower case.
Now 21a2 works beautifully.

Ype


From my previous note:

...
>.. if the call originates from within jython. I suspect this call is
>from a $py.class file that was compiled with 2.1a1.

That is indeed the case. I'll remove the class files, and inform you
early next week.

>In the announcement or in the release note, I should have pointed out
>that is it necessary to delete existing $py.class files and recompile
>frozen applications when upgrading to 2.1a2.

Thanks guys,
Ype

_______________________________________________
Jython-dev mailing list
Jyt...@li...
http://lists.sourceforge.net/lists/listinfo/jython-dev

Re: [Jython-dev] zip files on sys.path

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

[Samuele]

>Hi. A silly question:

Not silly at all.

>if foopkg is a package imported from a jar should:
>...
># vaguely inspired by jar: urls
>foopkg.__path__ = [SyspathArchiveXXX('foo.jar!/foopkg')]

I have updated the patch to follow this behaviour:

  foopkg.__path__ == [SyspathArchive('foo.jar!foopkg')]

The magic string -> SyspathArchive works on all paths of this form, but
it will cause the archive to be opened each such a string is found on
sys.path. Hardly a problem I think.

>PS: I write this before I forget about it:
>in general (I mean across the various jvms), if ins is a stream
>obtained from a ZipFile
>
>ins.read(buf,len,av) != av
>
>I have been already bitten a few times by that. Maybe that will improve
>in the future. We should check if the old class/source reading code takes care 
>of that.

Oh, right.

I remeber an even worse bug in some JVM (JDK1.1) where reading just one
byte beyond the size of the zip entry caused a EOFException (instead of
returning -1). The bug depends on the input file so it is damn hard to
test against.

The patch fixes both situation by reading the whole zip entry in a byte
array before returning the stream to the caller.

regards,
finn

[Jython-dev] [ jython-Patches-442166 ] zipfiles on syspath.

[<no...@so...>]

Patches item #442166, was opened at 2001-07-17 14:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=442166&group_id=12867

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Finn Bock (bckfnn)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfiles on syspath.

Initial Comment:
A patch that attempt to add some support for a 
different deployment of jython applications. Some of 
the ideas which have been discussed under the title of 
poor man freezing are included, but the patch does not 
attempt to include everything.

Here is what the patch adds:

- zip files can be added to sys.path.
- The zipfile will be kept open by the sys.path list 
by replacing the string in sys.path with a string   
subclass (SyspathArchive). The zipfile is closed by GC 
and all imported modules are unloaded.
- The zipfiles is scanned by the first import after 
adding the zip file to syspath and the result is 
always stored in cachedir.

Saving the scan result on the zipfile in cachedir is 
somewhat controversial if the goal is to create a 
fully self-contained and self-executable jython 
application. OTOH I still don't think it is a big 
problem saving the scan-index in cachedir during 
development. For a deployed application we will have 
to somehow save the scan results for all the java .jar 
files inside the applications.

When we do that, we can also add new main startup 
class which will look for the main python script name 
and other startup options in the manifest file. 


The patch does *not* attempt to:

- avoid dynamic proxy creation.
- allow importing .py files from classpath .jars
- allow importing jythonc'ed modules in the 
interpreter.
- etc.


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

>Comment By: Finn Bock (bckfnn)
Date: 2001-07-22 05:54

Message:
Logged In: YES 
user_id=4201

A new version of the patch which adds support the paths 
like "myjar.jar!foo/bar". This syntax is now also used for 
the __path__ field in subpackages.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=442166&group_id=12867

Re: [Jython-dev] bug in 2.1a2

[Ype K. <yk...@xs...>]

Finn, Samuele,

>[Ype]
>
>> Traceback (most recent call last):
>>   File "e:\pypr\TST\TST1.py", line 1, in ?
>>     from pqp import pqxt
>> java.lang.NoSuchMethodError: java.lang.NoSuchMethodError: org.python.core.Py: method
>> newCode(I[Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;IZZLorg/python/core/PyFunctionTable
>> ;I[Ljava/lang/String;[Ljava/lang/String;I)Lorg/python/core/PyCode; not found
>
>[Samuele]
>
>>That's strange, it seems something that compilation should have discovered?
>
>.. if the call originates from within jython. I suspect this call is
>from a $py.class file that was compiled with 2.1a1.

That is indeed the case. I'll remove the class files, and inform you
early next week.

>In the announcement or in the release note, I should have pointed out
>that is it necessary to delete existing $py.class files and recompile
>frozen applications when upgrading to 2.1a2.

Thanks guys,
Ype

[Jython-dev] [ jython-Patches-442906 ] Console encoding.

[<no...@so...>]

Patches item #442906, was opened at 2001-07-19 14:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=442906&group_id=12867

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Finn Bock (bckfnn)
Assigned to: Samuele Pedroni (pedronis)
Summary: Console encoding.

Initial Comment:
A patch that allow a different encoding used in the 
console.

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

>Comment By: Finn Bock (bckfnn)
Date: 2001-07-21 02:44

Message:
Logged In: YES 
user_id=4201

I committed a far better fix to the syntax error in bug 
#439688. As a result, the second version of this patch only 
deals with changing the console encoding.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=442906&group_id=12867