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

Re: [Jython-dev] Installer test

[Jeff T. <je...@so...>]

On Tue, 31 Oct 2000, Finn Bock wrote:

> Hi 
> 
> I have tried to create an installer for the current snapshot of jython.
> I have used the free (GPL) LiftOff program to create the self installing
> .class file.
> 
>    http://sourceforge.net/projects/liftoff/
> 
> The installer is 1.5 Mb and contains also the standard python library
> which have previously been distributed as pylib15x.jar
> 
>    ftp://jython.sourceforge.net/pub/jython/Install.class
> 
> We have not made any decisions that LiftOff should be used, so please
> look at this as part of an evaluation of installers.
> 
> I have only tested this on win2k (with jdk1.3, jdk1.1.7a & MS-jview
> 5.00.3229). Feedback from other platforms and JVMs is needed before we
> can decide whether LiftOff is useful to us. 
> 
> Please try the installer and post your experience, both good and bad,
> here on the list. Give special attention to the two generated scripts.
> With some luck these should work on unixes and windows. 

Everything went fine (rh6.0, jdk1.2.2), except the two shell scripts
(jython and jythonc) were in DOS file format, and wouldn't execute:

~/jython-2.0pa0$ ./jythonc
bash: ./jythonc: No such file or directory

Also, the jython script had set:

JAVA_HOME=/home/jeff/jdk1.2.2/jre

Usually I have JAVA_HOME to /home/jeff/jdk1.2.2. I had not checked
the "jre" button on the installer. The script worked okay.

> 
> The text shown as license and readme should not be taken for anything
> other than examples. This also include the graphics used.

Hmm.. so the use of a GPL'ed installer won't affect jython's license?

--Jeff

> 
> I had to fix some bugs in LiftOff which occurred on windows
> (line-ending, slash/backslash) and LiftOff is GPL so the modified
> version is here:
> 
>    ftp://jython.sourceforge.net/pub/jython/liftoff-001031.tar.gz
> 
> regards,
> finn
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/jython-dev
> 

RE: [Jython-dev] Installer test

[Adam B. <ada...@gb...>]

Worked fine for NT 4 SP6 and Sun SDK 2 for java -version 
Classic VM (build JDK-1.2.2-001, native threads, symcjit)

even though I probably shouldn't be using JIT.

My testing was pretty minor (1+2=3, for i in x : print i, javac b.py where
b.py is fairly trivial) but that would still seem to confirm the installer
works fine.  The only problem was it couldn't find README.txt to display at
the end of the install.

try path E:\tempinstall\jp\
can not find readme text README.txt

Adam Burke

> -----Original Message-----
> From:	bc...@wo... [SMTP:bc...@wo...]
> Sent:	Wednesday, November 01, 2000 8:12 AM
> To:	jyt...@li...
> Subject:	[Jython-dev] Installer test
> 
> Hi 
> 
> I have tried to create an installer for the current snapshot of jython.
> I have used the free (GPL) LiftOff program to create the self installing
> .class file.
> 
>    http://sourceforge.net/projects/liftoff/
> 
> The installer is 1.5 Mb and contains also the standard python library
> which have previously been distributed as pylib15x.jar
> 
>    ftp://jython.sourceforge.net/pub/jython/Install.class
> 
> We have not made any decisions that LiftOff should be used, so please
> look at this as part of an evaluation of installers.
> 
> I have only tested this on win2k (with jdk1.3, jdk1.1.7a & MS-jview
> 5.00.3229). Feedback from other platforms and JVMs is needed before we
> can decide whether LiftOff is useful to us. 
> 
> Please try the installer and post your experience, both good and bad,
> here on the list. Give special attention to the two generated scripts.
> With some luck these should work on unixes and windows. 
> 
> The text shown as license and readme should not be taken for anything
> other than examples. This also include the graphics used.
> 
> I had to fix some bugs in LiftOff which occurred on windows
> (line-ending, slash/backslash) and LiftOff is GPL so the modified
> version is here:
> 
>    ftp://jython.sourceforge.net/pub/jython/liftoff-001031.tar.gz
> 
> regards,
> finn
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/jython-dev

[Jython-dev] Installer test

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

Hi 

I have tried to create an installer for the current snapshot of jython.
I have used the free (GPL) LiftOff program to create the self installing
.class file.

   http://sourceforge.net/projects/liftoff/

The installer is 1.5 Mb and contains also the standard python library
which have previously been distributed as pylib15x.jar

   ftp://jython.sourceforge.net/pub/jython/Install.class

We have not made any decisions that LiftOff should be used, so please
look at this as part of an evaluation of installers.

I have only tested this on win2k (with jdk1.3, jdk1.1.7a & MS-jview
5.00.3229). Feedback from other platforms and JVMs is needed before we
can decide whether LiftOff is useful to us. 

Please try the installer and post your experience, both good and bad,
here on the list. Give special attention to the two generated scripts.
With some luck these should work on unixes and windows. 

The text shown as license and readme should not be taken for anything
other than examples. This also include the graphics used.

I had to fix some bugs in LiftOff which occurred on windows
(line-ending, slash/backslash) and LiftOff is GPL so the modified
version is here:

   ftp://jython.sourceforge.net/pub/jython/liftoff-001031.tar.gz

regards,
finn

[Jython-dev] Builtin code module.

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

Hi,

I want to remove the builtin "code" module from jython and replace it
with the code.py from CPython2.0. The Lib/code.py files will then also
be removed. This is primary because IDLE require the real code.py. 

This will break code that depends on the current builtin "code" module
or depends on the fact that this code module is always available. If
such code exists, the workaround is to use the builtin "codeop" instead.

Comments, gripes?

regards,
finn

Re: [Jython-dev] Coercing floats to java ints.

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

[Finn]
> But this cause silent loss of information, so I would prefer that we fix
> the documentation. Does anyone have a strong opinion about this?

I agree that's better to change the doc than to have a info losing coercion.

For the rest: I'm working on the prec,... things.

regards, Samuele

[Jython-dev] Coercing floats to java ints.

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

Hi,

Daniel Wood discovered that a python float does not autocoerce to a java
int when passed to a java method.

Jython 2.0 pre-alpha on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import java
>>> java.lang.Integer(1.0)
Traceback (innermost last):
  File "<console>", line 1, in ?
TypeError: java.lang.Integer(): 1st arg can't be coerced to int or
String
>>>


The documentation in usejava.html says that floats will be converted to
ints, so there is a bug in either the docs or in the code. But which is
it?

Fixing the code could look like this:

Index: PyFloat.java
===================================================================
RCS file: /cvsroot/jython/jython/org/python/core/PyFloat.java,v
retrieving revision 2.2
diff -u -r2.2 PyFloat.java
--- PyFloat.java        1999/10/04 22:21:46     2.2
+++ PyFloat.java        2000/10/29 19:26:28
@@ -68,6 +68,9 @@
         if (c == Float.TYPE || c == Float.class) {
             return new Float(value);
         }
+        if (c == Integer.TYPE || c == Integer.class) {
+            return new Integer((int) value);
+        }
         return super.__tojava__(c);
     }



But this cause silent loss of information, so I would prefer that we fix
the documentation. Does anyone have a strong opinion about this?

regards,
finn

Re: [Jython-dev] *loading

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

Hi.

[Finn]
> [Samuele]
>
> >Let's do that way. If you mean the gathering of frozen packages info,
plus
> >the initProxy,initProps,runMain stuff,
>
> I will commit this soon. The list of modules is passed to
> Py.initProperties() which right now only prints the list for debugging
> purposes. The list looks like this:
>
>    String[] modules = { "p0.__init__", "a", "p0.x" }
>
> Is this what you need?

It should be ok, otherwise I can adjust your code, if that does not disturb
you.

> >I imagine I can also fix the two last bugs: very likely the first as part
of
> >the findattr rewriting.
>
> I assume bug #2 must be solved in jythonc. (Pity we can't re-use the
> algorithm for searching for modules from jython itself)

Yes, it's a jythonc bug.

> >[Finn]
> >>>(a little note) Differently from jython, jythonc follows
> >>>the proposed precedence py > java. For the rest (java loading)
> >>>it uses the org.python.core runtime. Is that true?
> >>
> >>I don't think so. jythonc creates a list of known java packages and
> >>passes this list on to sys.add_package() during initialization. This
> >>creates PyJavaPackages which is currently searched before the python
> >>modules. I think. But hey, you're the expert <wink>.
> >
> >I just hope I'm the expert ;). Sorry for the confusion. I was referring
to
> >the jythonc handling of import stmt
> >at compilation time, not to the interaction between compiled code and
jython
> >runtime.
>
> Ohh, I see. I'm entirely sure about that either, but it does seem to be
> the case. I'll look further into this and maybe fix bug #2.

I have studied the code for tracking bug #2. In order to solve it one should
give jythonc ImportName.lookupName
information about the package of the module in which the involved import is.
The information is somehow around.
It is clearly needed to construct the path necessary for relative lookup.

I have just started working on the rest.

regards, Samuele

Re: [Jython-dev] *loading

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

[Samuele]

>Let's do that way. If you mean the gathering of frozen packages info, plus
>the initProxy,initProps,runMain stuff,

I will commit this soon. The list of modules is passed to
Py.initProperties() which right now only prints the list for debugging
purposes. The list looks like this:

   String[] modules = { "p0.__init__", "a", "p0.x" }

Is this what you need? 

>I imagine I can also fix the two last bugs: very likely the first as part of
>the findattr rewriting.

I assume bug #2 must be solved in jythonc. (Pity we can't re-use the
algorithm for searching for modules from jython itself)

>I will disable the unfinished support for poor freezing, we once reffered
>to.

Ok. I have no problem with that.

>And the loading of python modules from mixed java/python pkgs, because with
>the new precedence this is no more necessary and just confusing, there will
>be only python pkgs that eventually shadow java pkgs but leaving access to
>them, or
>not shadowed pure java pkgs.

Exactly. This is one of the reason I believe that we are onto something
good.

>[Finn]
>>>(a little note) Differently from jython, jythonc follows
>>>the proposed precedence py > java. For the rest (java loading)
>>>it uses the org.python.core runtime. Is that true?
>>
>>I don't think so. jythonc creates a list of known java packages and
>>passes this list on to sys.add_package() during initialization. This
>>creates PyJavaPackages which is currently searched before the python
>>modules. I think. But hey, you're the expert <wink>.
>
>I just hope I'm the expert ;). Sorry for the confusion. I was referring to
>the jythonc handling of import stmt
>at compilation time, not to the interaction between compiled code and jython
>runtime. 

Ohh, I see. I'm entirely sure about that either, but it does seem to be
the case. I'll look further into this and maybe fix bug #2.

regards,
finn

[Jython-dev] Backlog cleared.

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

Samuele,

I just commit some minor changes, most of it have already been discussed
here. However, since one of the changes touched some of the sources you
must work on also, a "cvs update" will be prudent.

regards,
finn

Re: [Jython-dev] *loading

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

Hi.

[Finn]
>
> [Samuele]
> >I clarified to myself that jythonc should build the list, use the new
> >order dealing with imports but it is not necessary that it find out
> >that a py pkg is also a java pkg :). The modified runtime support
> >can deal with this.
>
> [Finn]
> >I can make this change. Py.initProxy will then get a new "String[]
> >modules" argument. I'll make it a patch,, i.e I will not commit this
> >until we have settled the complete semantic change.
>
> [Samuele]
> >> During the next weekend I will somehow start experimenting with
> >> merging PyJava*Packages and sys.path java load support.
> >> So we will have some experience about this.
> >
> >Given the flat sematic for sys.path java loading (no dynamic __path__'s)
> >there is nothing to experiment with, fixing things to the new semantic
> >should be simple (and make code cleaner),
> >up to jpythonc building the list (but I think it already gathers that
> >information)
>
> Correct, it does.
>
> >and how radically can we change PackageManager, but I don't
> >think its interface was intended to be public up to the sys.add_package
> >door that will still be there.
>
> I can't quite parse the paragraph above, but I think sys.add_package is
> just about the only intended public interface to the PackageManager.
>
> >It is really just Barry turn to express his opinions and concerns.
>
> Let's not necessarily wait for that. Everybody who have spoken up agrees
> that the new precedence is an improvement. With an implementation
> available we can get some real world feedback from the users that are
> tracking the CVS.
>
> The precedence we are talking about can be described like this:
>
>   Known frozen pys > sys.path (py) > java pkgs > sys.path (java)
>
> I'll get the necessary changes to jythonc ready by saturday.
>

Yes that's the precedence we're talking about.

Let's do that way. If you mean the gathering of frozen packages info, plus
the initProxy,initProps,runMain stuff,
I can work on the rest (the famous
PackageManager,findattrs,PyJava*Package,BytecodeLoader) during the weekend
and for next week.

I imagine I can also fix the two last bugs: very likely the first as part of
the findattr rewriting.

I will disable the unfinished support for poor freezing, we once reffered
to.
And the loading of python modules from mixed java/python pkgs, because with
the new precedence this is no more necessary and just confusing, there will
be only python pkgs that eventually shadow java pkgs but leaving access to
them, or
not shadowed pure java pkgs.

I would like to have poor freezing + loading from classpath/jars of python
pkgs in interpreted mode,
but we can think about it later. For the moment I hope there is nobody
around who really relies on
undocumented/unfinished stuff. The documented part of the story, -jar option
and __run__.py will still
be supported.

[Finn]
>>(a little note) Differently from jython, jythonc follows
>>the proposed precedence py > java. For the rest (java loading)
>>it uses the org.python.core runtime. Is that true?
>
>I don't think so. jythonc creates a list of known java packages and
>passes this list on to sys.add_package() during initialization. This
>creates PyJavaPackages which is currently searched before the python
>modules. I think. But hey, you're the expert <wink>.

I just hope I'm the expert ;). Sorry for the confusion. I was referring to
the jythonc handling of import stmt
at compilation time, not to the interaction between compiled code and jython
runtime. About that
your picture is exact.

regards, Samuele

Re: [Jython-dev] *loading

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

[Samuele]
>I clarified to myself that jythonc should build the list, use the new
>order dealing with imports but it is not necessary that it find out
>that a py pkg is also a java pkg :). The modified runtime support
>can deal with this.

[Finn]
>I can make this change. Py.initProxy will then get a new "String[]
>modules" argument. I'll make it a patch,, i.e I will not commit this
>until we have settled the complete semantic change.

[Samuele]
>> During the next weekend I will somehow start experimenting with
>> merging PyJava*Packages and sys.path java load support.
>> So we will have some experience about this.
>
>Given the flat sematic for sys.path java loading (no dynamic __path__'s)
>there is nothing to experiment with, fixing things to the new semantic
>should be simple (and make code cleaner),
>up to jpythonc building the list (but I think it already gathers that 
>information) 

Correct, it does.

>and how radically can we change PackageManager, but I don't
>think its interface was intended to be public up to the sys.add_package
>door that will still be there.

I can't quite parse the paragraph above, but I think sys.add_package is
just about the only intended public interface to the PackageManager.

>It is really just Barry turn to express his opinions and concerns.

Let's not necessarily wait for that. Everybody who have spoken up agrees
that the new precedence is an improvement. With an implementation
available we can get some real world feedback from the users that are
tracking the CVS.

The precedence we are talking about can be described like this:

  Known frozen pys > sys.path (py) > java pkgs > sys.path (java) 

I'll get the necessary changes to jythonc ready by saturday.

regards,
finn

Re: [Jython-dev] two (more) bugs (?)

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

[Samuele]

>Let's consider the following module/pkg/dir hierarchy:
>TOP/
> a.py
> p0/
>  __init__.py
>  x.py
>  y.py
>  p1/
>  __init__.py
>  z.py
>  
>all python files just contain:
>print __name__
>
>except a.py:
>
>import p0.x
>
>print __name__
>
>and x.py:
>
>import y
>import p1.z
>
>print __name__
>
>(0) If one executes a.py from TOP with CPython 1.5/1.6/2.0 everything
> works fine.
> 
>(1) Jython instead fails to locate p1 relative to x package (stmt import p1.z in 
>x.py).
>
>Built-in Package Support in Python 1.5 
>( http://www.python.org/doc/essays/packages.html )
>
>is not explicit about loading packages relative to modules in pkgs, it only
>speaks about module (but pkgs "are" modules) rel. import, in any case CPython 
>behaviour is to find p1 package relative to x package p0 completing import p1.z 
>in x.py.
>So jython seems buggy in this respect.

I agree, this is bug. Complex python applications depends on this
relative behaviour, so it should be fixed. OTOH, since no one have
reported the bug it does not have get a high priority.

(Once on python-dev, it was suggested that relative imports should look
in each package, the whole way up the package structure. If my memory
serves me right, there was a very high level of agreement that this
would be a good thing)

>Notice that jython correctly locate y.
>
>(2) If one compiles a.py with jythonc and the --deep option,
>p0.y will not be compiled. The relative import rule is ignored
>by jythonc. In my opinion this is a bug, and I know how possibly
>fix this.

Also a bug IMO. Also a low priority for the same reasons.

>Both bugs are better solved in the "grand" *loading cleanup...
>
>(a little note) Differently from jython, jythonc follows
>the proposed precedence py > java. For the rest (java loading)
>it uses the org.python.core runtime. Is that true?

I don't think so. jythonc creates a list of known java packages and
passes this list on to sys.add_package() during initialization. This
creates PyJavaPackages which is currently searched before the python
modules. I think. But hey, you're the expert <wink>.

regards,
finn

[Jython-dev] two (more) bugs (?)

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

Hi.

Let's consider the following module/pkg/dir hierarchy:
TOP/
 a.py
 p0/
  __init__.py
  x.py
  y.py
  p1/
  __init__.py
  z.py
  
all python files just contain:
print __name__

except a.py:

import p0.x

print __name__

and x.py:

import y
import p1.z

print __name__

(0) If one executes a.py from TOP with CPython 1.5/1.6/2.0 everything
 works fine.
 
(1) Jython instead fails to locate p1 relative to x package (stmt import p1.z in 
x.py).

Built-in Package Support in Python 1.5 
( http://www.python.org/doc/essays/packages.html )

is not explicit about loading packages relative to modules in pkgs, it only
speaks about module (but pkgs "are" modules) rel. import, in any case CPython 
behaviour is to find p1 package relative to x package p0 completing import p1.z 
in x.py.
So jython seems buggy in this respect.
Notice that jython correctly locate y.

(2) If one compiles a.py with jythonc and the --deep option,
p0.y will not be compiled. The relative import rule is ignored
by jythonc. In my opinion this is a bug, and I know how possibly
fix this.

Both bugs are better solved in the "grand" *loading cleanup...

(a little note) Differently from jython, jythonc follows
the proposed precedence py > java. For the rest (java loading)
it uses the org.python.core runtime. Is that true?
 

Remarks are welcome.

regards, Samuele

Re: [Jython-dev] JavaCC-2.0 on Mac

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

I once wrote:

>We may have a problem with JavaCC-2.0 on (some?) Macs. Frode Reinsnes
>have tested errata-09 (which uses JavaCC-1.1) and encountered a
>ArrayIndexOutOfBoundsException.
>
>http://www.python.org/pipermail/jpython-interest/2000-October/006356.html

There are now more info available: 

[Frode Reinsnes]

>I have trace the problem lintel more down. The problem is in FillBuff. and
>the problem occure when you try to read one char in the last posison in the
>buffer. That mean theat maxNextCharInd == bufsize-1.
>
>        if ((i = inputStream.read(buffer, maxNextCharInd,
>                                    available - maxNextCharInd)) == -1)
>
>
>A call to inputStream.read(buffer,buffer.length-1,1) will return a larg
>negativ number. This is perhaps a bug in MRJ2.2?

I would say it is a bug in MRJ2.2. It is however a bug that will hurt
jython when used under that version of the JVM.

The return value of Reader.read(b,o,l) is documented as:

"""
   The number of characters read, or -1 if the end of the stream
   has been reached
"""

The inputStream is actually a

  new InputStreamReader(
        new BufferedInputStream(
              new FileInputStream(new File(modname + ".py"))))

I suspect it is the ByteToCharConverter in the InputStreamReader, that
somehow get confused and return a wrong length.

I still have no clue what to do about it.

regards,
finn

[Jython-dev] Argument parser helper.

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

Hi,

When updating sre to handle keyword argument in patter.sub(..) and
frieds, I needed some helper function to scan, error check and find
keyword parameters. 
Basicly the same as CPython's PyArg_ParseTupleAndKeywords. 

Below is such a utility class which I suggest shuold be added to core.

A typical use will look like this:

    public MatchObject search(PyObject[] args, String[] kws) {
        ArgParser ap = new ArgParser("search", args, kws, 
                                     "pattern", "pos", "endpos");
        String string = ap.getString(0);
        int start     = ap.getInt(1, 0);
        int end       = ap.getInt(2, string.length());
        ...


The ctor gets the function name, the actual arguments/keywords and 
the expected keyword names. Some checks are then performed by the 
ArgParser constructor.

The values are then extracted using the ap.getXXX() methods. In the
example, the first "pattern" argument is required (therefore no default
value is specified). The last two arguments have a default value given
as the second parameter to ap.getXXX().

If this is wrong, badly named or not general enough, speak up now.

regards,
finn


package org.python.core;

/**
 * A utilityclass for handling mixed positional and keyword arguments.
 * 
 * A typical usage:
 * <pre>
 *  public MatchObject search(PyObject[] args, String[] kws) {
 *      ArgParser ap = new ArgParser("search", args, kws, 
 *                                   "pattern", "pos", "endpos");
 *      String string = ap.getString(0);
 *      int start     = ap.getInt(1, 0);
 *      int end       = ap.getInt(2, string.length());
 *      ...
 * </pre>
 */

public class ArgParser {
    // The name of the function. Used in exception messages
    private String funcname;

    // The actual argument values.
    private PyObject[] args;

    // The list of actual keyword names.
    private String[] kws;

    // The list of allowed and expected keyword names.
    private String[] params = null;

    // A marker.
    private static Object required = new Object();


    private ArgParser(String funcname, PyObject[] args, String[] kws) {
        this.funcname = funcname;
        this.args = args;
        this.kws = kws;
    }

    public ArgParser(String funcname, PyObject[] args, String[] kws,
                     String p0) {
        this(funcname, args, kws);
        this.params = new String[] { p0 };
        check();
    }

    public ArgParser(String funcname, PyObject[] args, String[] kws, 
                     String p0, String p1) {
        this(funcname, args, kws);
        this.params = new String[] { p0, p1 };
        check();
    }

    public ArgParser(String funcname, PyObject[] args, String[] kws,
                     String p0, String p1, String p2) {
        this(funcname, args, kws);
        this.params = new String[] { p0, p1, p2 };
        check();
    }

    public ArgParser(String funcname, PyObject[] args, String[] kws, 
                     String[] paramnames) {
        this(funcname, args, kws);
        this.params = paramnames;
        check();
    }


    public String getString(int pos) {
         return (String) getArg(pos, String.class, "string");
    }

    public String getString(int pos, String def) {
         return (String) getArg(pos, String.class, "string", def);
    }


    public int getInt(int pos) {
         return getRequiredArg(pos).__int__().getValue();
    }

    public int getInt(int pos, int def) {
         PyObject value = getOptionalArg(pos);
         if (value == null)
             return def;
         return value.__int__().getValue();
    }


    public PyObject getPyObject(int pos) {
         return getRequiredArg(pos);
    }

    public PyObject getPyObject(int pos, PyObject def) {
         PyObject value = getOptionalArg(pos);
         if (value == null)
             value = def;
         return value;
    }



    private void check() {
        l1:
        for (int i = 0; i < kws.length; i++) {
            for (int j = 0; j < params.length; j++) {
                if (kws[i].equals(params[j]))
                    continue l1;
            }
            throw Py.TypeError(kws[i] + " is an invalid keyword argument " +
                               "for this function");
        }
    }

    private PyObject getRequiredArg(int pos) {
        PyObject ret = getOptionalArg(pos);
        if (ret == null)
            throw Py.TypeError(funcname + ": The " + ordinal(pos) + 
                               " argument is required");
        return ret;
    }

    private PyObject getOptionalArg(int pos) {
        int kws_start = args.length - kws.length;
        if (pos < kws_start)
            return args[pos];
        for (int i = 0; i < kws.length; i++) {
            if (kws[i].equals(params[pos]))
                return args[kws_start + i];
        }
        return null;
    }


    private Object getArg(int pos, Class clss, String classname) {
        return getArg(pos, clss, classname, required);
    }

    private Object getArg(int pos, Class clss, String classname, Object def) {
        PyObject value = null;
        if (def == required)
            value = getRequiredArg(pos);
        else {
            value = getOptionalArg(pos);
            if (value == null)
                return def;
        }

        Object ret = value.__tojava__(clss);
        if (ret == Py.NoConversion) 
            throw Py.TypeError("argument " + (pos+1) + ": expected " +
                               classname + ", " + Py.safeRepr(value) +
                               " found");
        return ret;
    }


    private static String ordinal(int n) {
        switch(n+1) {
        case 1:
            return "1st";
        case 2:
            return "2nd";
        case 3:
            return "3rd";
        default:
            return Integer.toString(n+1)+"th";
        }
    }
}

Re: [Jython-dev] *loading

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

Hi.

[Finn]
> >I clarified to myself that jythonc should build the list, use the new
> >order dealing with imports but it is not necessary that it find out
> >that a py pkg is also a java pkg :). The modified runtime support
> >can deal with this.
> 
> I can make this change. Py.initProxy will then get a new "String[]
> modules" argument. I'll make it a patch,, i.e I will not commit this
> until we have settled the complete semantic change.

[me]
> During the next weekend I will somehow start experimenting with
> merging PyJava*Packages and sys.path java load support.
> So we will have some experience about this.

Given the flat sematic for sys.path java loading (no dynamic __path__'s)
there is nothing to experiment with, fixing things to the new semantic
should be simple (and make code cleaner),
up to jpythonc building the list (but I think it already gathers that 
information) and how radically can we change PackageManager, but I don't
think its interface was intended to be public up to the sys.add_package
door that will still be there.

It is really just Barry turn to express his opinions and concerns.


regards, Samuele.

Re: [Jython-dev] Build hierachy...

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

[Dj]

>I know this is minor but it has been quietly bugging me.
>
>Shouldn't the org directory in the jython tree be inside a src directory
>rather than
>having the top of the package hierachy appearing?

It was organized so in JPython-1.0 and was changed in the 1.1beta's.

Personally, I rather like the new layout. I suspect that Barry does too.
Perhaps this preference have something to do with the fifth rule of The
Zen of Python:

  - Flat is better than nested.

regards,
finn

[Jython-dev] *loading

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

Hi.

During the next weekend I will somehow start experimenting with
merging PyJava*Packages and sys.path java load support.
So we will have some experience about this.


regards, Samuele.

[Jython-dev] Build hierachy...

[Dj <dj...@ru...>]

I know this is minor but it has been quietly bugging me.

Shouldn't the org directory in the jython tree be inside a src directory
rather than
having the top of the package hierachy appearing?

PS. After building a new build.xml which handled the javacc and jjtree
stuff as "exec" processes, the new release of Ant 1.2 came out which has
javacc and jjtree as built in tasks so I'm redoing it with that at the
moment.

Dj

RE: [Jython-dev] A license question

[Tim P. <ti...@em...>]

[Finn Bock]
> I have made a "sha" module based on source from cryptix. Their license
> "The cryptix general license" is claimed to a Berkeley License.
>
>   http://www.cryptix.org/docs/license.html

Yes, that's "the new" Berkeley License (w/ a different copyright holder),
and not even the FSF <wink> will have a problem with it.

> The source SHA1.java contains the complete license text from the link
> above. The sha.__doc__ also contains the complete license text. By this
> I hope to have complied with both conditions, but before I commit it I
> want to be sure ...
>
> Would it cause problems for users if some parts of jython are covered by
> such a license?

It should be fine -- it doesn't obligate them in any way, except to refrain
from removing the copies of the license you added.  There are a few similar
files in the CPython implementation, and nobody ever complained about them
there either.

too-many-licenses-are-a-weariness-of-the-soul-ly y'rs  - tim

[Jython-dev] A license question

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

Hi,

I have made a "sha" module based on source from cryptix. Their license
"The cryptix general license" is claimed to a Berkeley License.

  http://www.cryptix.org/docs/license.html

The source SHA1.java contains the complete license text from the link
above. The sha.__doc__ also contains the complete license text. By this
I hope to have complied with both conditions, but before I commit it I
want to be sure ...

Would it cause problems for users if some parts of jython are covered by
such a license? 

regards,
finn

Re: [Jython-dev] Build tools...

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

[Dj]

>... Can jython be built with the
>current version (2.0) of javacc or are we still locked on the old version

We have moved to version javacc-2.0.

regards,
finn

Re: [Jython-dev] Build tools...

[<ba...@wo...>]

>>>>> "D" == Dj  <dj...@ru...> writes:

    D> Yup, I skipped that. (I'll get right on to it). Can jython be
    D> built with the
    D> current version (2.0) of javacc or are we still locked on the
    D> old version (and if so, anyone got a copy they could send me; I
    D> can't find the old one anywhere).

JavaCC 2.0 works just fine now!

-Barry

Re: [Jython-dev] Build tools...

[Dj <dj...@ru...>]

Finn Bock wrote:

> One thing that is missing in your build.xml is the handling of
> org/python/parser/python.jjt, first by jjtree and then by javacc.

Yup, I skipped that. (I'll get right on to it). Can jython be built with the

current version (2.0) of javacc or are we still locked on the old version
(and
if so, anyone got a copy they could send me; I can't find the old one
anywhere).

Dj

Re: [Jython-dev] Build tools...

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

[Dj]

>After grabbing jython, I threw a quick ant build.xml file together...

Great. I never got around to do it myself.

>then I thought I'd better ask if there was actually a mandated build
>procedure for
>jython.

No. Barry use "make" on his unix, I just do a "jikes *.java" in each
directory manually. 

>I quite like the look of Ant as it keeps the portability up.

Me too. 

One thing that is missing in your build.xml is the handling of
org/python/parser/python.jjt, first by jjtree and then by javacc. If you
add that (and the corresponding clean commands), I'll include your
build.xml in the cvs.

regards,
finn