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

[Jython-dev] =?ks_c_5601-1987?B?anl0aG9uLWRldrTUsrIgv/m15cTFIMfRsbnA/CDGvMTPwLsgteW4s7TPtNku?=

[<ev...@jo...>]

DQoNCg0KICAgudq5zLfJtNSysi4uLi0tPiAgICAgKMHWKcG2wMy6qiC15biyICAgodogMjAw
MiC79cfYIL+sx8/Eq7XlILq4s7ux4iCh2iCwobHuv+4gxKOxuCAzutC/obDUILq4s7vB1ry8
v+QhISEgILndteW9wyAzutC/obDUIMSrteW4piC6uLO7wda8xb7fuLgNCiDAzLqlxq6/oSDA
wLjwtcqw+iC1v73Dv6EgtOfDt8DHILHiyLiwoSDB1r7uwf20z7TZLiC6uLO7tMK757b3IMDM
uKcgRS1tYWlsILnetMIgu+e29yDAzLinIEUtbWFpbCANCg0Kud7Aur3FILjewM/AuiC5373F
IMD8v+vAzLnHt84gyLi9xcDMILrSsKG0ycfVtM+02S4gICAgICAgICAgICAgICCi0bz2vcWw
xbrOIA0KDQoNCg0K

[Jython-dev] Visual

[Clifford R. <Cli...@gt...>]

Is there a visual developement tool for Python.

Clifford Robinson 
Systems Administrator 
Information Technology 
GTSOFTWARE INC. 
Cli...@GT... 

 

Re: [Jython-dev] Re: Using Jython with Java Web Start

[Samuele P. <ped...@bl...>]

> [Samuele]
> 
> >The problem here is that there are two choices:
> >1) loading the $py.class through loadClass
> >2) load it as a resource (work only with Java 2 unless
> > the .class extension is changed to something else)
> 
> Generally speaking, I have no problem if this new feature only works for
> java2. I also like the possibility of adding some other toplevel path
> component to the entries in the .ar file, eg. Lib/string$py.class.
> 
> So I'm leaning towards #2 myself.

I see, but I should repeat that it means you cannot package
modules that way with an untrusted applet, because
option #2 requires the permissions to create classloader.
A solution could be that we have sys.classLoader with #1
and sys.path things with #2.
 
 
> I disagree with both your positions <wink>.
> 
> I feel that classloader loading should be handled like zip loading.
> Users should somehow be able to add a classloader to sys.path (maybe
> with an additional top-level path component). No hardcoded precedence
> policy needed.
> 

OK for me, that probably means that sys.classLoader should
be integrated in the new picture. 
Anyway we could use some kind of string wrapper in this
case too, to deal for example with subpackages.

regards, Samuele Pedroni.

Re: [Jython-dev] Re: Using Jython with Java Web Start

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

[Phil Surette]

> [..] Would it be hard to get it to load from .class files as well? Or
> is that not the issue?

[Samuele]

>The problem here is that there are two choices:
>1) loading the $py.class through loadClass
>2) load it as a resource (work only with Java 2 unless
> the .class extension is changed to something else)

Generally speaking, I have no problem if this new feature only works for
java2. I also like the possibility of adding some other toplevel path
component to the entries in the .ar file, eg. Lib/string$py.class.

So I'm leaning towards #2 myself.

[Phil Surette]

> First, if I understand the code correctly, the classloader would take
> precedence over the python.path. 

The code I posted was only meant as a temporary hack to enable
deployment for WebStart users. Hardly worth discussing the finer detail
of such a crude hack.

[Phil Surette]

> Since the python.path is specific
> to python, IMO python.path should take precedence over the 
> classloader for loading python modules. I.e. you 
> should try to delegate to the importer before trying the classloader.
> [There should probably be a registry setting for this!]

[Samuele] 

>IMHO it is a sensible thing for the classloader to take over
>sys.path in this case. Sys path in some occasion should even
>be ignored. It makes also sense wrt to Java behavior:
>java -jar  ignores the classpath!.

I disagree with both your positions <wink>.

I feel that classloader loading should be handled like zip loading.
Users should somehow be able to add a classloader to sys.path (maybe
with an additional top-level path component). No hardcoded precedence
policy needed.

regards,
finn

Re: [Jython-dev] Re: Using Jython with Java Web Start

[Samuele P. <ped...@bl...>]

> > It isn't general enough and it doesn't work.
> >
> > It can only import top-level modules. Modules in packages can't be
> > imported. That can be fixed by enabling the snippet in PyModule that is
> > commented out.
> >
> 
> Uncomment? :)

:) I commented out that code and at that time the feature
 support was already disabled (no cal loadFromClassLoader).
 And this is a sensible
thing as you have seen, more thoughts and code are needed
to support this properly. 
 
> > Other issues with the patch are:
> >
> > - Only support for .py files. That is too slow for a general solution.
> 
> Okay. Would it be hard to get it to load from .class files as well? Or
> is that not the issue?

The problem here is that there are two choices:
1) loading the $py.class through loadClass
2) load it as a resource (work only with Java 2 unless
 the .class extension is changed to something else)

With 1)  there is no need to create a classloader
and to have the corresponding permissions. OTOH
only 2) allows for class unloading.

For the scenarios I imagine 1) should be just fine.
Then there could be a performance problem
doing trial-and-error through loadClass when
we are loading module classes remotely. 
At least for jythonc produced code there
is a mechanism in place that  deals
with that possible problem, so maybe we need
to replicate that mechanism (which means
you have to explicitly list the py modules in
your jar) in this new context,
although is probably just a Java 1.1
issue (pre jar caching).

All solutions are OK for me, but 
the combinations we want to support should
be chosen.

> > - Setting __path__ to None to signal classloader is probably OK for a
> >   specialized solution, but we have to come up with something more
> >   general.
> > - The classloader is hardcoded. Eventually a user want to put the python
> >   modules into a .jar loaded by another classloader.
> >
> 
> Agreed. My main motivation is to be able to create a jython jar with
> the python modules in it and carry that around as a complete unit.
> I just want to be able to go java -jar jython.jar and in this case 
> everything is in the system classloader.
> 
> The problem I wanted to solve is now solved with -Dpython.path 
> /path/to/jar/python/subpath command-line option.  Perhaps that
> option was always there, but it's not obvious (better now that
> the ! was replaced with a /). Anyway, it unfortunately does not
> solve Duane's problem.
> 
> > All in all, more though have to go into this. We also want to
> > restructure the "imp" code a bit. At the moment a lot of logic is
> > duplicated in loadFromZipFile and loadFromPath. The loadFromClassLoader
> > method will eventually contain the same logic one more time.
> >
> > I understand the desire for this feature, I just don't think we are able
> > to add it the Right Way in version 2.1.
> >
> 
> I'm glad to hear that you understand the desire for the feature!
> 
> >
> > Instead we could maybe make the loadFromClassLoader() method public and
> > suggest that embedding user temporarily use the hack below to load
> > python modules from their classloader. The hack must be explicit enabled
> > with a call like this:
> >
> >     org.python.util.ClassLoaderImport.install()
> >
> > Comments?
> >
> 
> First, if I understand the code correctly, the classloader would take
> precedence over the python.path. Since the python.path is specific
> to python, IMO python.path should take precedence over the 
> classloader for loading python modules. I.e. you 
> should try to delegate to the importer before trying the classloader.
> [There should probably be a registry setting for this!]
> 

IMHO it is a sensible thing for the classloader to take over
sys.path in this case. Sys path in some occasion should even
be ignored. It makes also sense wrt to Java behavior:
java -jar  ignores the classpath!.

> As to which classloader to use, I agree with you that it is bad
> to have the classlader hardcoded to imp's classloader. In 
> java 2 environments maybe some combination like, try
> the context classloader, then the system classloader, then
> imp's classloader, would work. I haven't thought through the
> proper order. Probably it should be configurable. 
> 
> I'd like to be able to enable the hack from the registry. Then, if I 
> read the documentation on the registry correctly, you could
> add a registry to jython.jar with the appropriate property enabled
> and you're away. The property name could be 'allowImportFromClassloader'
> and there could be related properties like 
> 'classloaderImportPrecedence=context,system,class'.
> 
> I realize I'm suggesting a lot of registry settings and I have no
> idea how much work this would be. But I would say that
> if adding these settings is too much for 2.1, then 
> just leave classloading until until there is time to do it right. 

Given the input from other people it seem that we should
be able to deal with defaults and also arbitrary new classloaders,
 at least
for java classes (unrelated) but then also for py modules
to have a coherent picture.

[Also the role of sys.classLoader should be considered,
and when sys.path defaults to empty or is ignored.]

> Thanks, finn, for taking an interest in this issue! 

We have always been interested in this issue,
although I admit quite silently <wink>.

regards, Samuele Pedroni.

Re: [Jython-dev] Re: Using Jython with Java Web Start

[Phil S. <phi...@is...>]

On Saturday 22 December 2001 03:15 pm, Finn Bock wrote:
> [Phil Surette]
>
> >I submitted a patch to support this to jython-dev a while back.
>
> I'm sorry that I didn't reply to you back then.
>

No problem.

> >After poking through the jython code, I found that this patch to
> >org/jython/core/imp.java in jython-2.1a3 does the trick:
> >imp.java
> >498a499,502
> >
> >> //if it's not a builtin or in the python path, try the classpath
> >> ret = loadFromClassLoader(name, imp.class.getClassLoader());
> >> if (ret != null) return ret;
>
> It isn't general enough and it doesn't work.
>
> It can only import top-level modules. Modules in packages can't be
> imported. That can be fixed by enabling the snippet in PyModule that is
> commented out.
>

Uncomment? :)

> Other issues with the patch are:
>
> - Only support for .py files. That is too slow for a general solution.

Okay. Would it be hard to get it to load from .class files as well? Or
is that not the issue?

> - Setting __path__ to None to signal classloader is probably OK for a
>   specialized solution, but we have to come up with something more
>   general.
> - The classloader is hardcoded. Eventually a user want to put the python
>   modules into a .jar loaded by another classloader.
>

Agreed. My main motivation is to be able to create a jython jar with
the python modules in it and carry that around as a complete unit.
I just want to be able to go java -jar jython.jar and in this case 
everything is in the system classloader.

The problem I wanted to solve is now solved with -Dpython.path 
/path/to/jar/python/subpath command-line option.  Perhaps that
option was always there, but it's not obvious (better now that
the ! was replaced with a /). Anyway, it unfortunately does not
solve Duane's problem.

> All in all, more though have to go into this. We also want to
> restructure the "imp" code a bit. At the moment a lot of logic is
> duplicated in loadFromZipFile and loadFromPath. The loadFromClassLoader
> method will eventually contain the same logic one more time.
>
> I understand the desire for this feature, I just don't think we are able
> to add it the Right Way in version 2.1.
>

I'm glad to hear that you understand the desire for the feature!

>
> Instead we could maybe make the loadFromClassLoader() method public and
> suggest that embedding user temporarily use the hack below to load
> python modules from their classloader. The hack must be explicit enabled
> with a call like this:
>
>     org.python.util.ClassLoaderImport.install()
>
> Comments?
>

First, if I understand the code correctly, the classloader would take
precedence over the python.path. Since the python.path is specific
to python, IMO python.path should take precedence over the 
classloader for loading python modules. I.e. you 
should try to delegate to the importer before trying the classloader.
[There should probably be a registry setting for this!]

As to which classloader to use, I agree with you that it is bad
to have the classlader hardcoded to imp's classloader. In 
java 2 environments maybe some combination like, try
the context classloader, then the system classloader, then
imp's classloader, would work. I haven't thought through the
proper order. Probably it should be configurable. 

I'd like to be able to enable the hack from the registry. Then, if I 
read the documentation on the registry correctly, you could
add a registry to jython.jar with the appropriate property enabled
and you're away. The property name could be 'allowImportFromClassloader'
and there could be related properties like 
'classloaderImportPrecedence=context,system,class'.

I realize I'm suggesting a lot of registry settings and I have no
idea how much work this would be. But I would say that
if adding these settings is too much for 2.1, then 
just leave classloading until until there is time to do it right. 

Thanks, finn, for taking an interest in this issue! 

By the way, I am still planning to submit some ant/jython
tasks to this group, and should actually have time
to do it between Christmas and New Year's.

> regards,
> finn
>
>
> package org.python.util;
>
> import org.python.core.*;
>
> public class ClassLoaderImport extends PyObject {
>     PyObject importer;
>
>     ClassLoaderImport(PyObject importer) {
>         this.importer = importer;
>     }
>
>     public PyObject __call__(PyObject args[], String keywords[]) {
>         if (!(args.length < 1 || args[0] instanceof PyString))
>             throw Py.TypeError("first argument must be a string");
>         if (keywords.length > 0)
>             throw Py.TypeError("__import__() takes no keyword "+
>                                "arguments");
>
>         int argc = args.length;
>         String module = args[0].__str__().toString();
>
>         PyObject globals = (argc > 1 && args[1] != null)
>             ? args[1] : null;
>         PyObject fromlist = (argc > 3 && args[3] != null)
>             ? args[3] : Py.EmptyTuple;
>
>         System.out.println("module:" + module);
>         PyObject ret = imp.loadFromClassLoader(module,
>
> imp.class.getClassLoader());
>         if (ret != null)
>             return ret;
>
>         return importer.__call__(args, keywords);
>     }
>
>
>     public static void install() {
>         PyObject builtin = Py.getSystemState().modules.
>                                         __finditem__("__builtin__");
>         PyObject importer = builtin.__getattr__("__import__");
>         builtin.__setattr__("__import__",
>                             new ClassLoaderImport(importer));
>     }
> }
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev

-- 
Phil Surette
phi...@is...
phi...@ya...
psu...@es...

[Jython-dev] Re: Using Jython with Java Web Start

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

[Phil Surette]

>I submitted a patch to support this to jython-dev a while back.

I'm sorry that I didn't reply to you back then.

>After poking through the jython code, I found that this patch to
>org/jython/core/imp.java in jython-2.1a3 does the trick:
>imp.java
>498a499,502
>> //if it's not a builtin or in the python path, try the classpath
>> ret = loadFromClassLoader(name, imp.class.getClassLoader());
>> if (ret != null) return ret;

It isn't general enough and it doesn't work.

It can only import top-level modules. Modules in packages can't be
imported. That can be fixed by enabling the snippet in PyModule that is
commented out.

Other issues with the patch are:

- Only support for .py files. That is too slow for a general solution.
- Setting __path__ to None to signal classloader is probably OK for a
  specialized solution, but we have to come up with something more
  general.
- The classloader is hardcoded. Eventually a user want to put the python
  modules into a .jar loaded by another classloader.

All in all, more though have to go into this. We also want to
restructure the "imp" code a bit. At the moment a lot of logic is
duplicated in loadFromZipFile and loadFromPath. The loadFromClassLoader
method will eventually contain the same logic one more time.

I understand the desire for this feature, I just don't think we are able
to add it the Right Way in version 2.1.


Instead we could maybe make the loadFromClassLoader() method public and
suggest that embedding user temporarily use the hack below to load
python modules from their classloader. The hack must be explicit enabled
with a call like this:

    org.python.util.ClassLoaderImport.install()

Comments?

regards,
finn


package org.python.util;

import org.python.core.*;

public class ClassLoaderImport extends PyObject {
    PyObject importer;

    ClassLoaderImport(PyObject importer) {
        this.importer = importer;
    }

    public PyObject __call__(PyObject args[], String keywords[]) {
        if (!(args.length < 1 || args[0] instanceof PyString))
            throw Py.TypeError("first argument must be a string");
        if (keywords.length > 0)
            throw Py.TypeError("__import__() takes no keyword "+
                               "arguments");

        int argc = args.length;
        String module = args[0].__str__().toString();

        PyObject globals = (argc > 1 && args[1] != null)
            ? args[1] : null;
        PyObject fromlist = (argc > 3 && args[3] != null)
            ? args[3] : Py.EmptyTuple;

        System.out.println("module:" + module);
        PyObject ret = imp.loadFromClassLoader(module,

imp.class.getClassLoader());
        if (ret != null)
            return ret;

        return importer.__call__(args, keywords);
    }


    public static void install() {
        PyObject builtin = Py.getSystemState().modules.
                                        __finditem__("__builtin__");
        PyObject importer = builtin.__getattr__("__import__");
        builtin.__setattr__("__import__",
                            new ClassLoaderImport(importer));
    }
}

Re: [Jython-dev] my posts to jython-users@lists.sourceforge.net are showing up

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

[Updike, Clark]

>I've submitted the post below twice to jyt...@li...
>(last night and again just now) and it doesn't show up.  Also, I'm not
>getting a bounced email either.  What up?

I've noticed that the SF mail lists are very slow at the moment.

>TIA,
>Clark (please reply to mailto:cla...@jh...)
>
>p.s.  Barry, I worked with your bro Craig at C1 until I left in September.
>
>Subject:  2.1b2 PyServlet.loadServlet 'invalid syntax'   
>Sent:  12/22/2001 10:28 AM 
> Importance:  Normal   
>I'm trying to run the Hello.py servlet example but I get the exception from
>PyServlet.loadServlet() shown below.  The strange thing is that I can
>execute the statement execfile('C:\\Program Files\\Apache Tomcat
>4.0\\webapps\\JythonServlet\\Hello.py') from the interactive interpreter
>without getting the 'invalid syntax' problem (which I think shows that the
>path is valid). 

I agree. That was a good test.

>Anyone have any ideas?
>
>TIA, 
>Clark 
>
>javax.servlet.ServletException: Could not create Jython servletTraceback
>(innermost last): 
>  (no code object) at line 0 
>SyntaxError: ('invalid syntax', ('C:\\Program Files\\Apache Tomcat
>4.0\\webapps\\JythonServlet\\Hello.py', 3, 9, '        class
>Hello(javax.servlet.http.HttpServlet):'))

I notice the spaces (or tabs) before the class statement in the error
message. Does the source file have any whitespace there? It mostly
likely shouldn't have any.

regards,
finn

[Jython-dev] my posts to jython-users@lists.sourceforge.net are showing up

[Updike, C. <Cla...@jh...>]

I've submitted the post below twice to jyt...@li...
(last night and again just now) and it doesn't show up.  Also, I'm not
getting a bounced email either.  What up?

TIA,
Clark (please reply to mailto:cla...@jh...)

p.s.  Barry, I worked with your bro Craig at C1 until I left in September.

Subject:  2.1b2 PyServlet.loadServlet 'invalid syntax'   
Sent:  12/22/2001 10:28 AM 
 Importance:  Normal   
I'm trying to run the Hello.py servlet example but I get the exception from
PyServlet.loadServlet() shown below.  The strange thing is that I can
execute the statement execfile('C:\\Program Files\\Apache Tomcat
4.0\\webapps\\JythonServlet\\Hello.py') from the interactive interpreter
without getting the 'invalid syntax' problem (which I think shows that the
path is valid).  Anyone have any ideas?

TIA, 
Clark 

javax.servlet.ServletException: Could not create Jython servletTraceback
(innermost last): 
  (no code object) at line 0 
SyntaxError: ('invalid syntax', ('C:\\Program Files\\Apache Tomcat
4.0\\webapps\\JythonServlet\\Hello.py', 3, 9, '        class
Hello(javax.servlet.http.HttpServlet):'))

        at org.python.util.PyServlet.loadServlet(PyServlet.java) 
        at org.python.util.PyServlet.getServlet(PyServlet.java) 
        at org.python.util.PyServlet.service(PyServlet.java) 
<snip> 

P.S. 
The exception is from this code block in PyServlet.java, loadServlet(): 

         try { 
            interp.execfile(path); 
            PyObject cls = interp.get(name); 
            if (cls == null) 
                throw new ServletException("No callable (class or function)
"+ 
                                       "named " + name + " in " + path); 

            PyObject pyServlet = cls.__call__(); 
            Object o = pyServlet.__tojava__(HttpServlet.class); 
            if (o == Py.NoConversion) 
                throw new ServletException("The value from " + name + 
                                       "must extend HttpServlet"); 
            servlet = (HttpServlet)o; 
            servlet.init(getServletConfig()); 

        } catch (PyException e) { 
            throw new ServletException("Could not create "+ 
                                       "Jython servlet" + e.toString()); 
        }  

 

[Jython-dev] [ jython-Patches-478763 ] import case sensitivity

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

Patches item #478763, was opened at 2001-11-06 08:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=478763&group_id=12867

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

Initial Comment:
A patch for bug #451552. It reverse the lookup order 
so that java packages is checked before java classes. 
The patch also verifies that the case of a directory 
is correct.

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

>Comment By: Samuele Pedroni (pedronis)
Date: 2001-12-20 16:24

Message:
Logged In: YES 
user_id=61408

Integrated in:
  PathPackageManager.java 1.6
  PyJavaPackage.java 2.17
  imp.java 2.59

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

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

Re: [Jython-dev] javaos.py for OS/400

[Kevin B. <kb...@ca...>]

Sorry for the slow reply - we've moved houses and had all sorts of
complications, the most minor of which is I no longer have a home 
internet connection (I'm going back to 56K RSN).  This has not 
been a productive couple of weeks.

Humbel Otmar wrote:
> 
> Hi Kevin, others
> 
> I slowly begin to understand why Finn did not want to write this one :-)

:-)

> I can successfully issue quite complex commands like:

cool!

> However, there are some commands for which I didn't find a way to pass
> hyphenated options to, like:
>     os.system('alias -p')
> - no idea why. Now I have to check each command if it accepts options
> starting with '-', this will take some time ... . I see no solution at
> the moment, I can only document these commands.

That is strange.  My guess is it is another character set issue, and that the EBCDIC (?) string argument passed to 'qsh -c "EBCDIC STRING -HERE"' has the wrong character.  Hmm.  Yeah, sounds crazy to me, too.

Maybe you could try echoing the commands, or maybe change the 'println' and 'printlnStdErr' functions to write( map( ord, arg ) + "\n" ), and see what the actual characters passed were?  


The following may also yield interesting information:

	Runtime.getRuntime().exec( ["qsh", "-c", "echo alias -p"] )
	Runtime.getRuntime().exec( ["qsh", "-c", "echo", "alias", "-p"] )
	Runtime.getRuntime().exec( ["echo", "alias", -p"] )

	system( "python printOrd.py -p" )  where printOrd.py does:  import sys;print map( ord, sys.argv[1] )

Also, the use of string.split & not passing to qsh is worrisome - it
means that trying to quote arguments and/or use environment variables
in commands would fail (unless we use expandvars & complicate
'split'):

	os.system( 'jvm LookupInfo "Kevin Butler" "$USERNAME"' )

will get mapped to:

        Runtime.exec([ 'jvm', 'LookupInfo', '"Kevin', 'Butler"', '"$USERNAME"' ])

How does it fail if it is executed as follows?

        Runtime.exec( ['qsh', '-c', 'jvm LookupInfo "Kevin Butler" "$USERNAME"']) 


> Please also notice the jvm=1 flag in the 'java -classpath' command:
> os.system needs to be telled if a JVM is going to be started, because in
> this case the encoding is different. In fact, IF a jvm is started, I can
> use your (Kevin's) code unchanged :-)

If we could make the 'jvm=' flag something more like an encoding
specification, I'd like it better. This may require figuring out
exactly what is causing the two cases to behave differently.

I did a little searching/reading:

http://www.as400.ibm.com/developer/java/devkit/rzaha116.htm#HDRRZAHA-JCERF

Sounds like reading from stdin and writing to stdout encode character
data using the AS/400 job CCSID (coded character set identifier),
while reading with an InputStreamReader and writing to an
OutputStreamWriter encode/decode using the file.encoding property.

The linked pages:

http://www.as400.ibm.com/developer/java/devkit/rzaha118.htm#HDRRZAHA-DFVRF
- shows many CCSIDs mapping to ISO 8859_1 as the default

http://www.as400.ibm.com/developer/java/devkit/rzaha117.htm#HDRRZAHA-FEVACRF
- shows ISO_8859_1 mapping to CCSID 819 as the closest map - but 819 isn't listed above (!)?

Also, it looks like the default CCSID is 37 - which looks like it
should be EBCDIC, and the default file.encoding for CCSID 37 is ISO
8859_1.  Hmm.

Looks like i18n.jar has a file encoding for international EBCDIC (Cp500),
and the AS/400 page indicates there is an encoding for IBM US EBCDIC (Cp037).

So how about this?

...

class _StreamInfo:
    """Holds the buffered stream and some other useful info.
    Handy to pass around as a parameter.
    """
    def __init__( self, stream, jvm=0 ):
        encoding = sys.registry.getProperty( "jython.encoding", System.getProperty( "file.encoding" ) )    
        self.setBufferedStream( BufferedReader(InputStreamReader(stream), encoding) )
        self.setJvm( 0 )

And then try the following:

sys.registry.setProperty( "jython.encoding", "Cp037" )
system( "ls -l" )
system( "java -Dfile.encoding=Cp037 HelloWorld" ) # requires a HelloWorld
system( "java -Dfile.encoding=Cp500 HelloWorld" ) # requires a HelloWorld

> Now my questions:
> Is this 'extension' to os.system() - it will silently ignore the jvm
> flag on most platforms - acceptable ?

If we can't make it generally useful, we may want to put most of it in a 'javaos400.py' or some such, but we can determine that as needed...

> Shall I proceed ?
> If you tell me this has little chances to be checked into cvs, then I'll
> give up my 'two-hours-a-day-research'.
> I attach the current javaos.py FYI (It still needs to be worked over,
> though).

I think it is valuable - and I'm learning things from your research, too!  :-)

> PS. I think it would not be a big think to replace re, since we are only
> using re.match(), won't it ?

No, that shouldn't be hard if we decide we need to, but it doesn't sound like there is a need at this point.

kb

[Jython-dev] [ jython-Patches-495611 ] Beginning of Jython-2.2

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

Patches item #495611, was opened at 2001-12-20 13:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=495611&group_id=12867

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Finn Bock (bckfnn)
Assigned to: Finn Bock (bckfnn)
Summary: Beginning of Jython-2.2

Initial Comment:
This is a dirty hack!

In order to weed out some anti-jython code in the 
CPython testcases, I have made a series of quick 
modifications so that I could run some of the 
testcases. 

Everything here is incomplete and with total disregard 
to style.

I promise *not* to commit these changes.


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

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

Re: [Jython-dev] problem with multi level import

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

[Matt_Conway]

>[...] I just fixed a problem with jreload 
>(ClassFormatError due to truncated class data because when loading the 
>class from the stream, it does a single read instead of looping reads till 
>EOS), 

Yeah, we have several of those left. I believe the only truely solid way
of reading a zipfile entry is when it's done as in
SyspathArchive.getInputStream().

>so I'll submit that patch using SF sometime today.
>I assume that when doing a "cvs diff -u", I should do a "clean" build 
>first so that none of the build cruft shows up in the patch?

Or trim the cruft from the patch with an editor.

>Also, if I know that I only changed a single source file, can I do the 
>"cvs diff -c" on just that file?

Sure.

>Does the current directory matter when 
>doing the diff, or can I be in the directory containing the file? i.e. 
>which of the following is preferred:
>"cvs diff -c jython/org/python/core/imp.java"
>or
>"cd jython/org/python/core; cvs diff -c imp.java"

For a single file or single directory patch, I prefer the second
example. Either way, we'll manage.

>> If you *really* want to help out, you should have made a SF bug report
>> with your observation (there is still time to make amends <wink>) and a
>
>Heh, ok, if I get a chance today I'll do it, lots to get done before my 
>vacation starts so no guarantees =)

Too late.

regards,
finn

Re: [Jython-dev] problem with multi level import

[<Mat...@i2...>]

On 12/19/2001 02:06:17 PM jython-dev-admin wrote:
>
> >If I have to do more complicated changes, whats the best way for me to
> >generate a patch?
> 
> 1) Check out the CVS version.
> 2) Edit the sources until it works for you.
> 3) run "cvs diff -u" to generate a patch.
> 4) Add the patch on SF.
>    http://sourceforge.net/tracker/?group_id=12867&atid=312867
> 5) [Most important] Do not post the patch to a mailing list.

Ok, cool, thanks for the info - I just fixed a problem with jreload 
(ClassFormatError due to truncated class data because when loading the 
class from the stream, it does a single read instead of looping reads till 
EOS), so I'll submit that patch using SF sometime today.
I assume that when doing a "cvs diff -u", I should do a "clean" build 
first so that none of the build cruft shows up in the patch?
Also, if I know that I only changed a single source file, can I do the 
"cvs diff -c" on just that file?  Does the current directory matter when 
doing the diff, or can I be in the directory containing the file? i.e. 
which of the following is preferred:
"cvs diff -c jython/org/python/core/imp.java"
or
"cd jython/org/python/core; cvs diff -c imp.java"

> If you *really* want to help out, you should have made a SF bug report
> with your observation (there is still time to make amends <wink>) and a

Heh, ok, if I get a chance today I'll do it, lots to get done before my 
vacation starts so no guarantees =)

Matt

[Jython-dev] =?ISO-2022-JP?B?GyRCJE8hPCQkISobKEI=?=

[<cy...@ma...>]

<REFUSE>
女性に優しい出会い

●女性スタッフみんなで作った女性に優しいサイトだよ。
もちろん無料。あなたが望む彼を見つけてね。
新機能搭載☆
http://cyu.5151.jp/
男性は無料ポイント実施中。優しいあなたを待ってます。
もちろん、i-mode,j-sky,ezweb,PCに対応。
http://cyu.5151.jp/
いい出会いを・・・・MAN&WOMAN

Re: [Jython-dev] problem with multi level import

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

[Matt Conway]

>Hi,
>
>I had a problem with multi level import from a jar file in my sys.path.
>basically, my simple test jar looks as follows, with the init files being 
>empty, and the py files having a simple variable def:
>
>jlib.jar:
>Lib/
>Lib/aaa/
>Lib/aaa/__init__.py
>Lib/aaa/bbb/
>Lib/aaa/bbb/__init__.py
>Lib/aaa/bbb/ccc/
>Lib/aaa/bbb/ccc/__init__.py
>Lib/aaa/bbb/ccc/yyy.py
>Lib/aaa/bbb/xxx.py
>
>
>import aaa works fine
>import aaa.bbb (or more levels) doesn't
>
>I traced the problem down to the following line from the method 
>"loadFromZipFile" on line 302 in org/python/core/imp.java
>                SyspathArchive subArchive = 
>zipArchive.makeSubfolder(modName);
>Which should probably be
>                SyspathArchive subArchive = 
>zipArchive.makeSubfolder(name);
>
>Or at least, when I change it to that, all levels of import work for me =)

For me too. Thanks for your patch.

>If I have to do more complicated changes, whats the best way for me to 
>generate a patch?

1) Check out the CVS version.
2) Edit the sources until it works for you.
3) run "cvs diff -u" to generate a patch.
4) Add the patch on SF.
   http://sourceforge.net/tracker/?group_id=12867&atid=312867
5) [Most important] Do not post the patch to a mailing list.

The reason for 5) is that everything but the simplest of changes gets
lost on mailing lists.

>I'm somewhat of a CVS/patch/diff newbie, so excuse me 
>if this is a simple question.  Do I need to have 2 CVS directories, one 
>untouched to generate the diff against?  

There can be reasons for using 2 directories, but we'll manage to make
sense of a CVS diff too.

Please also remember to use the -u or -c option to diff. A plain diff is
quite useless as a patch.

If you *really* want to help out, you should have made a SF bug report
with your observation (there is still time to make amends <wink>) and a
self contained copy&paste example. See below for one way of doing that.
Adding a SF bug report ensure that the situation will (eventually) be
addressed and that a note about a fix will be included in the release
note.

regards,
finn


import zipfile, time

def addZipEntry(zip, name, data):
    entry = zipfile.ZipInfo()
    entry.filename = name
    entry.date_time = time.gmtime(time.time())
    zip.writestr(entry, data)

zip = zipfile.ZipFile("test350.zip", "w")

addZipEntry(zip, "Lib/aaa/__init__.py", "print __name__")
addZipEntry(zip, "Lib/aaa/bbb/__init__.py", "print __name__")
addZipEntry(zip, "Lib/aaa/bbb/ccc/__init__.py", "print __name__")
addZipEntry(zip, "Lib/aaa/bbb/ccc/yyy.py", "print __name__")
addZipEntry(zip, "Lib/aaa/bbb/xxx.py", "print __name__")

zip.close()

import sys
sys.path.append("test350.zip/Lib")

import aaa
import aaa.bbb
import aaa.bbb.ccc
import aaa.bbb.ccc.yyy
import aaa.bbb.xxx

[Jython-dev] problem with multi level import

[<Mat...@i2...>]

Hi,

I had a problem with multi level import from a jar file in my sys.path.
basically, my simple test jar looks as follows, with the init files being 
empty, and the py files having a simple variable def:

jlib.jar:
Lib/
Lib/aaa/
Lib/aaa/__init__.py
Lib/aaa/bbb/
Lib/aaa/bbb/__init__.py
Lib/aaa/bbb/ccc/
Lib/aaa/bbb/ccc/__init__.py
Lib/aaa/bbb/ccc/yyy.py
Lib/aaa/bbb/xxx.py


import aaa works fine
import aaa.bbb (or more levels) doesn't

I traced the problem down to the following line from the method 
"loadFromZipFile" on line 302 in org/python/core/imp.java
                SyspathArchive subArchive = 
zipArchive.makeSubfolder(modName);
Which should probably be
                SyspathArchive subArchive = 
zipArchive.makeSubfolder(name);

Or at least, when I change it to that, all levels of import work for me =)

If I have to do more complicated changes, whats the best way for me to 
generate a patch?  I'm somewhat of a CVS/patch/diff newbie, so excuse me 
if this is a simple question.  Do I need to have 2 CVS directories, one 
untouched to generate the diff against?  Can someone give me a simple 
usage scenario as an example of generating a patch?  Thanks,

Matt

Re: [Jython-dev] Python object not gc()'d, 21b1

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

Samuele, Finn,

> >
>> Unfortunately Jython 2.1b1 doesn't inform you of the exception in the
>> way it should. When I fix that bug, your program will the same way, but
>> it will write:
>>
>
>The point is that java simply discards the exceptions thrown in finalizers.
>So we should catch them and print them explicitly for the __del__
>invocation in the finalizer.
>OTOH there is no leak.
>
>regards, Samuele Pedroni.

Thanks a lot to both of you. I think I am understanding more of the
'NameError: tracer' I reported before. It could well be that it is
also running a in cleared namespace.

I have a program that execfile()'s python modules in the namespace
of a new.module, ie. in it's __dict__ field. This programs clears
the __dict__ after the execfile in order to be able to reuse
the module object. However this seems to cause a NameError
once in a while, ie. when another thread tries to reference
the namespace of the module that has just been execfile()'d.

Should this program, instead of clearing the namespaces, just remove
all it's references to these namespaces, so they can be used as long as
necessary?


Regards,
Ype

Re: [Jython-dev] Python object not gc()'d, 21b1

[Samuele P. <ped...@bl...>]

> 
> Unfortunately Jython 2.1b1 doesn't inform you of the exception in the
> way it should. When I fix that bug, your program will the same way, but
> it will write:
> 

The point is that java simply discards the exceptions thrown in finalizers.
So we should catch them and print them explicitly for the __del__
invocation in the finalizer.
OTOH there is no leak.

regards, Samuele Pedroni.

Re: [Jython-dev] Python object not gc()'d, 21b1

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

[Ype Kingma]

>Dear jythoneers,
>
>This is a rather involved bug, so I hope it is JVM dependent.
>It shows up in rather unusual circumstances.

[example running __del__() method in clear globals snipped]

It isn't really a mystery and exactly the same thing happens in CPython.
When the __del__() is executed, the globals no longer have a reference
to the module level println function. The result is a common NameError
exception.

Unfortunately Jython 2.1b1 doesn't inform you of the exception in the
way it should. When I fix that bug, your program will the same way, but
it will write:

__main__.executor
Hello   <<unknown>.deltest1 instance at 6467398>
Hello2   <<unknown>.deltest2 instance at 5935979>
after del __main__.executor
Goodbye <<unknown>.deltest1 instance at 6467398>
Goodbye2 <<unknown>.deltest2 instance at 5935979>

__main__.clearingExecutor
Hello   <<unknown>.deltest1 instance at 13226366>
Goodbye <<unknown>.deltest1 instance at 13226366>
Hello2   <<unknown>.deltest2 instance at 14919969>
Exception NameError: println in <unbound method deltest2.__del__>
ignored
after del __main__.clearingExecutor


which at least contain a usefull hint about the real problem.

Thanks for making the example available. Without it, the bug would never
have been uncovered this easily.

regards,
finn

[Jython-dev] Java COllections and iterators

[James N. <jam...@ya...>]

has any progress been made or documented in making java containers and
python containers transparently intereact?

I define the following prototypes in java rather frequently

public void setMap(Map m)
public void setCollection(Collection c)
public void dosomething(Iterator i)

public getMap(){
return super.getBigStuffedTreeMap();}


using the above java declarations I would like to use python syntax


a={foo: "var"}
foo(a);
myMap=myObj.map## or myObj.getMap()
myVal=myObj.map["key"]


my experince in jpython was that java containers were more work instead of
less work when involving the jpython and it was almost as well to do all or
nothing in a single language.

I would love to learn that progress has been made or that someone in here
can point me to the relevant modules in the interp so I can try my own hand
at inermingling the collections classes


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [Jython-dev] Python object not gc()'d, 21b1

[Samuele P. <ped...@bl...>]

Hi,

use 
         print 'Goodbye2 ' + repr(self)
instead of
        println('Goodbye2 ' + repr(self))

and retry <wink>.

PS: the explanation is left as an exercise to the
reader :)

----- Original Message ----- 
From: Ype Kingma <yk...@xs...>
To: <jyt...@li...>
Sent: Monday, December 17, 2001 8:45 PM
Subject: [Jython-dev] Python object not gc()'d, 21b1


> Dear jythoneers,
> 
> This is a rather involved bug, so I hope it is JVM dependent.
> It shows up in rather unusual circumstances.
> 
> Showing the bug involves running the tstdel.py file
> from the command line. This program execfile()'s
> the modules tstdel1.py and tstdel2.py
> which differ only slightly.
> All three program files are included in this post, see below.
> 
> The tstdel.py program gives the output shown below.
> Each output line mentioning an object is printed
> from a constructor ('Hello' and 'Hello2') or
> from a __del__(self) method ('Goodbye' and Goodbye2')
> in the execfile()'d programs.
> 
> The output indicates that when using an object of 
> class executor the deltest2 object is correctly gc()'d.
> However when an object of class clearingExecutor is
> used the deltest2 object is not gc()'d, even after
> the clearingExecutor is del'ed:
> (jython 21b1, java 1.1.8, OS2)
> 
> <output from tstdel.py>
> 
> __main__.executor
> Hello   <<unknown>.deltest1 instance at 390229>
> Hello2   <<unknown>.deltest2 instance at 296443>
> after del __main__.executor
> Goodbye <<unknown>.deltest1 instance at 390229>
> Goodbye2 <<unknown>.deltest2 instance at 296443>
> 
> __main__.clearingExecutor
> Hello   <<unknown>.deltest1 instance at 298665>
> Goodbye <<unknown>.deltest1 instance at 298665>
> Hello2   <<unknown>.deltest2 instance at 293293>
> after del __main__.clearingExecutor
> 
> <end of output from tstdel.py>
> 
> Before the executor object is del'ed it references
> a deltest1 and a deltest2 object, and after the executor object
> is del'ed both the deltest1 object and the deltest2 object
> are __del__()'d. This is expected, and it might exclude the 
> possibility of dangling references from java classes created
> to perform execfile().
> 
> The clearingExecutor correctly clears the deltest1 instance
> from its self.glb, as is seen in the Goodbye from the deltest1
> instance at 298665, which is output before the next Hello2.
> 
> The bug:
> Even before deleting the clearningExecutor
> I would expect a Goodbye2 from the
> deltest2 instance at 293293.
> But this deltest2 instance is not __del__()'ed,
> not even after del'ing the clearingExecutor object.
> There seems to be a dangling reference
> to the deltest2 object at 293293.
> 
> 
> <The main program tstdel.py:>
> 
> from java.lang.System import gc, runFinalization
> from time import sleep
> 
> class executor:
>     def __init__(self):
>         self.glb = {}
> 
>     def exf(self, fnam):
>         execfile(fnam, self.glb, self.glb)
> 
> 
> class clearingExecutor:
>     def __init__(self):
>         self.glb = {}
> 
>     def exf(self, fnam):
>         execfile(fnam, self.glb, self.glb)
>         self.glb.clear()
> 
> 
> def cleanUp():
>     gc()
>     runFinalization()
>     sleep(2)
> 
> 
> x = executor()
> y = clearingExecutor()
> 
> print x.__class__
> 
> x.exf('tstdel1.py')
> cleanUp()
> 
> x.exf('tstdel2.py')
> cleanUp()
> 
> print 'after del', x.__class__
> del x
> 
> cleanUp()
> 
> print ''
> print y.__class__
> 
> y.exf('tstdel1.py')
> cleanUp()
> 
> y.exf('tstdel2.py')
> cleanUp()
> 
> print 'after del', y.__class__
> del y
> 
> cleanUp()
> 
> cleanUp()
> 
> 
> <end of tstdel.py>
> 
> <The tstdel1.py program:>
> 
> import java
> println = java.lang.System.out.println
> 
> class deltest1:
>     def __init__(self):
>         self.println = java.lang.System.out.println
>         self.println('Hello   ' + repr(self))
> 
>     def __del__(self):
>         self.println('Goodbye ' + repr(self))
> 
> td1 = deltest1()
> 
> <end of tstdel1.py>
> 
> The tstdel2.py program:
> 
> import java
> println = java.lang.System.out.println
> 
> class deltest2:
>     def __init__(self):
>         self.println = java.lang.System.out.println
>         self.println('Hello2   ' + repr(self))
> 
>     def __del__(self):
>         println('Goodbye2 ' + repr(self))
> 
> td2 = deltest2()
> 
> <end of tstdel2.py program>
> 
> The only difference (apart from names) between tstdel1.py and tstdel2.py
> is in the __del__() method. Class deltest2 references a
> function in module scope to provide its output, class deltest1
> uses the same function but as one of its attributes.
> 
> This difference seems to cause a deltest2 object to never become
> garbage when the dictionary against which tstdel2.py is executed
> is clear()'d.
> 
> It is possible that this bug is related to the 'NameError: tracer'
> I posted earlier (I gave up to isolate this possible bug).
> If/when these two are related a possible explanation would be
> that in some execution frame there is a wrong reference to an
> earlier frame. This could in this case form a dangling reference
> and in the 'NameError: tracer' case cause a deletion from the
> wrong namespace.
> 
> Again, I do hope that this one is platform dependent.
> If not, I'll gladly report a bug on sourceforge...
> 
> Have fun,
> Ype
> 
> P.S. 21b1 is otherwise working very well for me.
> 
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
> 

[Jython-dev] Python object not gc()'d, 21b1

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

Dear jythoneers,

This is a rather involved bug, so I hope it is JVM dependent.
It shows up in rather unusual circumstances.

Showing the bug involves running the tstdel.py file
from the command line. This program execfile()'s
the modules tstdel1.py and tstdel2.py
which differ only slightly.
All three program files are included in this post, see below.

The tstdel.py program gives the output shown below.
Each output line mentioning an object is printed
from a constructor ('Hello' and 'Hello2') or
from a __del__(self) method ('Goodbye' and Goodbye2')
in the execfile()'d programs.

The output indicates that when using an object of 
class executor the deltest2 object is correctly gc()'d.
However when an object of class clearingExecutor is
used the deltest2 object is not gc()'d, even after
the clearingExecutor is del'ed:
(jython 21b1, java 1.1.8, OS2)

<output from tstdel.py>

__main__.executor
Hello   <<unknown>.deltest1 instance at 390229>
Hello2   <<unknown>.deltest2 instance at 296443>
after del __main__.executor
Goodbye <<unknown>.deltest1 instance at 390229>
Goodbye2 <<unknown>.deltest2 instance at 296443>

__main__.clearingExecutor
Hello   <<unknown>.deltest1 instance at 298665>
Goodbye <<unknown>.deltest1 instance at 298665>
Hello2   <<unknown>.deltest2 instance at 293293>
after del __main__.clearingExecutor

<end of output from tstdel.py>

Before the executor object is del'ed it references
a deltest1 and a deltest2 object, and after the executor object
is del'ed both the deltest1 object and the deltest2 object
are __del__()'d. This is expected, and it might exclude the 
possibility of dangling references from java classes created
to perform execfile().

The clearingExecutor correctly clears the deltest1 instance
from its self.glb, as is seen in the Goodbye from the deltest1
instance at 298665, which is output before the next Hello2.

The bug:
Even before deleting the clearningExecutor
I would expect a Goodbye2 from the
deltest2 instance at 293293.
But this deltest2 instance is not __del__()'ed,
not even after del'ing the clearingExecutor object.
There seems to be a dangling reference
to the deltest2 object at 293293.


<The main program tstdel.py:>

from java.lang.System import gc, runFinalization
from time import sleep

class executor:
    def __init__(self):
        self.glb = {}

    def exf(self, fnam):
        execfile(fnam, self.glb, self.glb)


class clearingExecutor:
    def __init__(self):
        self.glb = {}

    def exf(self, fnam):
        execfile(fnam, self.glb, self.glb)
        self.glb.clear()


def cleanUp():
    gc()
    runFinalization()
    sleep(2)


x = executor()
y = clearingExecutor()

print x.__class__

x.exf('tstdel1.py')
cleanUp()

x.exf('tstdel2.py')
cleanUp()

print 'after del', x.__class__
del x

cleanUp()

print ''
print y.__class__

y.exf('tstdel1.py')
cleanUp()

y.exf('tstdel2.py')
cleanUp()

print 'after del', y.__class__
del y

cleanUp()

cleanUp()


<end of tstdel.py>

<The tstdel1.py program:>

import java
println = java.lang.System.out.println

class deltest1:
    def __init__(self):
        self.println = java.lang.System.out.println
        self.println('Hello   ' + repr(self))

    def __del__(self):
        self.println('Goodbye ' + repr(self))

td1 = deltest1()

<end of tstdel1.py>

The tstdel2.py program:

import java
println = java.lang.System.out.println

class deltest2:
    def __init__(self):
        self.println = java.lang.System.out.println
        self.println('Hello2   ' + repr(self))

    def __del__(self):
        println('Goodbye2 ' + repr(self))

td2 = deltest2()

<end of tstdel2.py program>

The only difference (apart from names) between tstdel1.py and tstdel2.py
is in the __del__() method. Class deltest2 references a
function in module scope to provide its output, class deltest1
uses the same function but as one of its attributes.

This difference seems to cause a deltest2 object to never become
garbage when the dictionary against which tstdel2.py is executed
is clear()'d.

It is possible that this bug is related to the 'NameError: tracer'
I posted earlier (I gave up to isolate this possible bug).
If/when these two are related a possible explanation would be
that in some execution frame there is a wrong reference to an
earlier frame. This could in this case form a dangling reference
and in the 'NameError: tracer' case cause a deletion from the
wrong namespace.

Again, I do hope that this one is platform dependent.
If not, I'll gladly report a bug on sourceforge...

Have fun,
Ype

P.S. 21b1 is otherwise working very well for me.

[Jython-dev] ADV:CREDIT CARD PROCESSING

[<in...@ca...>]

**********************************************************
To be removed from further mailings please respond to this 
email with "remove" in the subject line.
**********************************************************

Dear Friend,

Discover how you can accept credit cards directly from your 
website without ever having to purchase or lease expensive 
credit card equipment. If you are interested in learning
more please click on the link below. INSTANT ACCOUNT SET-UPS,
LOWEST RATES AND COMPLETE SHOPPINGCART SOLUTIONS AVAILABLE!

http://www.cards2go.com 

Feel free to call us @ 1.800.288.7363

If you prefer you can respond to this email@

mailto:si...@ca...

Please include NAME, PHONE# and best time to call.



IBS/PBS
7657 Winnetka
Canoga Park Ca

[Jython-dev] [ jython-Support Requests-441102 ] Unable to download 2.0 sources

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

Support Requests item #441102, was opened at 2001-07-13 09:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=212867&aid=441102&group_id=12867

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Bill Krueger (wkrue1)
Assigned to: Finn Bock (bckfnn)
Summary: Unable to download 2.0 sources

Initial Comment:
I'm getting the error msg: "linefeed expected in
cvsroot/jython/org/python/core/Java2Accessability.java,v"
when I do a checkout using the -r Release_2_0 option to
get the release 2.0 sources. 
The cvs command is "cvs -z3
-d:pserver:ano...@cv...:/cvsroot/jython
co -r Release_2_0 jython" and it downloads quite a bit
of code before the error hits. 

I'm wanting to reproduce a production environment that
currently uses jython 2.0  with some modifications and
using the 2.1alpha seems a bit of a risk. Any help
would be appreciated. 

thanks,

billK

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

>Comment By: Finn Bock (bckfnn)
Date: 2001-12-16 13:14

Message:
Logged In: YES 
user_id=4201

The "Release_2_0" tag is available now.

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

Comment By: Finn Bock (bckfnn)
Date: 2001-07-13 11:55

Message:
Logged In: YES 
user_id=4201

This problem is caused by a manual edit of the CVS 
repository. I hope we have the problems resolved soon.

regards,
finn

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

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