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

Re: [Jython-dev] bug in 2.1a2

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

> [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/c
ore/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. 
> 
> 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.
> 
You're right. Should something be posted to jython-users or put
on jython.org/SF?

Samuele.

Re: [Jython-dev] bug in 2.1a2

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

[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. 

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.

regards,
finn

[Jython-dev] bug in 2.1a2

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

Hi.

[In bug report by Ype Kingma]
> 
> 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/c
ore/PyFunctionTable
> ;I[Ljava/lang/String;[Ljava/lang/String;I)Lorg/python/core/PyCode; not found
> 
That's strange, it seems something that compilation should have discovered?

Samuele.

Re: [Jython-dev] Console encoding.

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

Hi,

> 1) The encoding for the console is stored in the CompilerFlags and
> passed into the parser. Samuele, how do you feel about reusing
> CompilerFlags for this purpose?
> 
I will look at that over the weekend.

Samuele

[Jython-dev] Jython Users

[Sean M. <sea...@pr...>]

Hello,

Just a note to say that Propylon use Jython to bring the power of Python to 
complex
XML processing on the Java Virtual Machine. Propylon also use Jython to provide
enhanced server-side scripting and integration in its pervasive portal server
product: Mission Control.

We would be happy to be listed on the jython users page on www.jython.org 
and will be linking to
jython.org from propylon.com shortly.

jython is an awesome accomplishment. Congrationalions!

Sean McGrath
CTO
Propylon

[Jython-dev] Console encoding.

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

I have added a patch which attempt to fix bug [ #439688 ] Syntax error
for non-ascii characters. 

>http://sourceforge.net/tracker/index.php?func=detail&aid=439688&group_id=12867&atid=112867	

The patch also attempt to define a different codec for the console and
it is this part of the patch that I seek some feedback for.

>http://sourceforge.net/tracker/index.php?func=detail&aid=442906&group_id=12867&atid=312867

Note: The wish for a different encoding for the console is a Windows
only issue. Changing the console encoding does not change the way all
other python sources is read.

1) The encoding for the console is stored in the CompilerFlags and
passed into the parser. Samuele, how do you feel about reusing
CompilerFlags for this purpose?

2) I can't find any way of detecting the encoding used for the console
so I have added two way the user can specify the encoding. An registry
options "python.console.encoding" and a command line options "-E codec".
By default the console will still use the file.encoding it does today.

Depending on what CPython comes up with regarding file encoding we may
also be able to change the encoding from within the console session.
 
The patch works on my danish windows when I specify the console encoding
as "cp850" using jdk.

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: 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.

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

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

[Jython-dev] www.jython.org/NEWS.htm without alpha2 news

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

In 

http://

the actual alpha2 new are missing.

Samuele.

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

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

Hi.

[Finn]
> [Samuele]
> 
> >+            } else if (bases[i] instanceof org.python.util.PyMetaClass) {
> 
> Putting PyMetaClass in org.python.util is bad for jythonc --core and
> --all options. I'll move it to core for the next release.
> 
(Now) I see the point. Feel absolutely free to do so.

Samuele.

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

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

[Samuele]

>+            } else if (bases[i] instanceof org.python.util.PyMetaClass) {

Putting PyMetaClass in org.python.util is bad for jythonc --core and
--all options. I'll move it to core for the next release.

regards,
finn

[Jython-dev] 2 Questions

[METilley <met...@ea...>]

Hi!

Here are my 2 questions:

(1)  I installed the JPython11.class file today (running "JPython" from the
'RUN' window in Windows 98/ME as instructed to do so in your install file),
and the JPython1.1 folder was created inside the c:\windows directory.  Is
this where it goes?  I didn't think so, so I uninstalled it.  Should I
specify the c:\python20 instead?  I want to be able to create Python
programs as well as JPython programs.

(2)  What is the difference between "JPython" and "Jython"?

Thank you, in advance.  I look forward to your responses.

Regards,
Merritt Tilley
Austin, TX.

[Jython-dev] Per Samuele's request - Posted to jython-dev

[Joseph C. <jca...@in...>]

Samuele,
Originally you had:

import org.python.core.*;
import org.python.util.*;

public class Test {

  public static void main(String[] args) {
    PythonInterpreter interp = new PythonInterpreter();
    interp.exec("class A:\n def m(self,a,b):\n  print a,b");
    PyClass A =(PyClass)interp.eval("A");
    PyInstance a = (PyInstance)A.__call__();
    PyObject m = A.__findattr__("m");    
                                                    
    interp.exec("class A:\n def m(self,a,b):\n  print b,a");
    PyClass A2 =(PyClass)interp.eval("A");
    PyInstance a2 = (PyInstance)A2.__call__();
    PyObject m2 = A2.__findattr__("m");        
    
    m2.__call__(a2,new PyInteger(1),new PyInteger(2));
    m.__call__(a,new PyInteger(1),new PyInteger(2)); 
    
  }
}

Which I agree works just fine... however if you modify to look like the 
following:

import org.python.core.*;
import org.python.util.*;

public class Test {

  public static void main(String[] args) {
    PythonInterpreter interp = new PythonInterpreter();
    interp.exec("class A:\n def m(self,a,b):\n  print a,b");
    interp.exec("class B(A):\n def n(self,a,b):\n  print a,b");

    PyClass class =(PyClass)interp.eval("B");
    PyInstance instance = (PyInstance)class.__call__();
    PyObject obj = instance.__findattr__("n");    

// This call works here.                                               
    obj.__call__(instance,new PyInteger(1),new PyInteger(2)); 
         
    interp.exec("class A:\n def m(self,a,b):\n  print a,b");
    interp.exec("class B(A):\n def n(self,a,b):\n  print a,b");

// This call doesn't work here.                                               
    obj.__call__(instance,new PyInteger(1),new PyInteger(2));     
  }
}

You should get the Trace telling you you have to call the unbound method with 
an instance first argument.

-- 
"Every new beginning comes from some other beginnings
end."
        -- Semisonic                 
-----------------------------------------------------
Joseph Campbell      | EMAIL: joe...@in...
Staff Consultant     | URL:   www.inventa.com
Inventa Technologies | PH:    (856)914-5224 
                     | CELL:  (609)972-0297
-----------------------------------------------------

[Jython-dev] [ jython-Patches-441369 ] ya import logic rework

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

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

Category: None
Group: None
Status: Closed
Resolution: None
Priority: 5
Submitted By: Samuele Pedroni (pedronis)
Assigned to: Samuele Pedroni (pedronis)
Summary: ya import logic rework

Initial Comment:
The patch should increase CPython comp
wrt import logic and solve

438108 __getitem__ called when it shouldn't? 

and other import bugs. The code is now more similar
to the CPython counterpart. Trying just to patch
the patched JPython logic again -I think - would not 
have been the right solution.

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

>Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-18 08:55

Message:
Logged In: YES 
user_id=61408

a fully working version of this <wink> has been committed.

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

Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-18 08:51

Message:
Logged In: YES 
user_id=61408

a fully working version of this <wink> has been committed.

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

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

[Jython-dev] [ jython-Patches-441369 ] ya import logic rework

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

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

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Samuele Pedroni (pedronis)
>Assigned to: Samuele Pedroni (pedronis)
Summary: ya import logic rework

Initial Comment:
The patch should increase CPython comp
wrt import logic and solve

438108 __getitem__ called when it shouldn't? 

and other import bugs. The code is now more similar
to the CPython counterpart. Trying just to patch
the patched JPython logic again -I think - would not 
have been the right solution.

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

>Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-18 08:51

Message:
Logged In: YES 
user_id=61408

a fully working version of this <wink> has been committed.

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

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

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

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

Hi. A silly question:

if foopkg is a package imported from a jar should:

# as with the patch
fookpkg.__path__ = [SyspathArchive('foo.jar')]

or

foopkg.__path__ = [SyspathArchiveXXX('foo.jar/foopkg')]

or

# vaguely inspired by jar: urls
foopkg.__path__ = [SyspathArchiveXXX('foo.jar!/foopkg')]

?

It's a matter of uniformity but maybe that's not that important.

Samuele. More later ...

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.

[Jython-dev] zip files on sys.path

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

I have posted my attempt to add some support for a different deployment
method 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.

>  http://sourceforge.net/tracker/index.php?func=detail&aid=442166&group_id=12867&atid=312867

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.

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.


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

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

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

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

Hi.

[pje]
> 
> Thanks!  This will be a big help for my project, as now I'll be able to use 
> ComputedAttributes in TransWarp without having to worry about there being 
> no way to do them in Jython.
> 
An "experimental" patch along the line of what we have discussed has
been committed; enjoy <wink>.

Samuele Pedroni.

Re: [Jython-dev] Long running process and Memory usage...

[Joseph C. <jca...@in...>]

the way it is working right now - I am compiling the code using the java 
PythonInterpreter Object... so I get a class, and then I get an Instance from 
that - all as Java Objects.  

pyInterp.exec(parent);
pyInterp.exec(child);

PyClass class = (PyClass) pyInterp.eval("childclass_name");
PyInstance instance = (PyInstance) class.__call__();
PyMethod method = class.__findattr__("method_name");

So what I tried to do originally is cache the objects listed above, in a 
seperate java object (A cache object specifically tailored to what I need).

I would then call the following to get a "result"

PyObject result = method.__call__(instance, data, data);

What I discovered was that If I were to take the same Python Interpreter and 
do the code again ("redo") with the same names but possibly different 
underlying code....

PyClass class2 = (PyClass) pyInterp.eval("childclass_name");
PyInstance instance2 = (PyInstance) class.__call__();
PyMethod method2 = class.__findattr__("method_name");

I would get the following when I attempted to run the "original" code from 
the cache objects.

PyObject result = method.__call__(instance, data, data);

threw the exception below:
TypeError: unbound method must be called with class instance 1st argument

So - I am fine cacheing the objects myself, but I must be doing something 
wrong...  Thoughts... please tell me I am a moron and am missing something 
very simple.
	Joe

On Tuesday 17 July 2001 14:39, you wrote:
> I don't know if you will get a different response from a more "official"
> source.  But I had the same problem recently.  From what I gathered this is
> by design, each time you execute python code, it recompiles it since the
> file may have changed and when a new class is loaded, the class def stays
> in memory.
>
> My way around it was to compile the classes and cache them myself, so when
> I needed to execute them again, I just used Py.runCode ( code, vars, vars )
> on it...it may also be an option to create java classes from them and call
> methods from there...
>
> Hope this helps...
>
> Pete
>
> -----Original Message-----
> From: Joseph Campbell [mailto:jca...@in...]
> Sent: Tuesday, July 17, 2001 11:23 AM
> To: jyt...@li...
> Subject: [Jython-dev] Long running process and Memory usage...
>
>
> Having a fairly large problem....
>
> I am currently using jython in a java embedded environment.  What is being
> done is Python code snips are being held in a database and based on
> information gotten via network protocol are pulled in compiled and used,
> the
>
> python source is held onto in a cache and the next time it is needed it is
> recompiled.
>
> So we have a situation like:
>
> class helper():
> 	def helpercode:
> 		Blah Blah
>
> class rule(helper):
> 	def isAlert(self, data):
> 		Blah Blah
>
> As example code from the DB.
>
> The problem I seem to be having is that the JVM is holding onto a great
> number of PyStrings, and pycode _pyx#### objects which are not being
> cleaned
>
> up by the GC.  Is this a known bug, or am I possobly doing something wrong
> in
> code that is forcing the VM to hold references it shouldn't?
>
> Thanks,
> 	Joe

-- 
"Every new beginning comes from some other beginnings
end."
        -- Semisonic                 
-----------------------------------------------------
Joseph Campbell      | EMAIL: joe...@in...
Staff Consultant     | URL:   www.inventa.com
Inventa Technologies | PH:    (856)914-5224 
                     | CELL:  (609)972-0297
-----------------------------------------------------

[Jython-dev] Long running process and Memory usage...

[Joseph C. <jca...@in...>]

Having a fairly large problem....

I am currently using jython in a java embedded environment.  What is being 
done is Python code snips are being held in a database and based on 
information gotten via network protocol are pulled in compiled and used, the 
python source is held onto in a cache and the next time it is needed it is 
recompiled.

So we have a situation like:

class helper():
	def helpercode:
		Blah Blah

class rule(helper):
	def isAlert(self, data):
		Blah Blah

As example code from the DB.

The problem I seem to be having is that the JVM is holding onto a great 
number of PyStrings, and pycode _pyx#### objects which are not being cleaned 
up by the GC.  Is this a known bug, or am I possobly doing something wrong in 
code that is forcing the VM to hold references it shouldn't?

Thanks,
	Joe

-- 
"Every new beginning comes from some other beginnings
end."
        -- Semisonic                 
-----------------------------------------------------
Joseph Campbell      | EMAIL: joe...@in...
Staff Consultant     | URL:   www.inventa.com
Inventa Technologies | PH:    (856)914-5224 
                     | CELL:  (609)972-0297
-----------------------------------------------------

[Jython-dev] PythonInterpreter() runtime error

[James D. <de...@sy...>]

Bryn, thanks for replying.  I am able to work with Jython interactively 
from the command line, but would like now to embed Jython scrips in my Java 
app.  I continue to get a troubling error when I attemp to run the 
SimpleEmbedded java routine found at http://jython.org/docs/embedding.html. 
 Perhaps you can help.  Below is a snip from another developer who 
experienced the same trouble (have pinged him also).  Have you seen this 
one before and if so, how is it corrected??

thanks in advance, Jim.

Ryan wrote:
For some reason I am having problems using the PythonInterpreter class when
I attempt to embed Jython.  There are no errors whatsoever when I compile,
but when I attempt to run it, I get this:

Exception in thread "main"
java.lang.NullPointerException
        at
org.python.core.PyJavaClass.lookup(PyJavaClass.java:39)
        at
org.python.core.PyObject.<init>(PyObject.java:46)
        at
org.python.core.PySingleton.<init>(PySingleton.java:8)
        at
org.python.core.PyNone.<init>(PyNone.java:7)
        at
org.python.core.PySystemState.initStaticFields(PySystemState.java:34)
        at
org.python.core.PySystemState.initialize(PySystemState.java:320)
        at
org.python.core.PySystemState.initialize(PySystemState.java:294)
        at
org.python.core.PySystemState.initialize(PySystemState.java:287)
        at
org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:61)
        at
org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:45)
        at
SimpleEmbedded.main(SimpleEmbedded.java:6)

Line 6 in SimpleEmbedded.java is
where the PythonIntepreter variable is
initialized.  This occurred when trying
to run the embed demo that comes with
Jython.  I am using the 1.3 SDK from Sun,
and Jython-2.0.  Any ideas?

Thanks,


-----Original Message-----
From:	br...@je... [SMTP:br...@je...]
Sent:	Wednesday, July 11, 2001 5:46 PM
To:	bc...@wo...; jyt...@li...
Cc:	de...@sy...
Subject:	RE: [Jython-dev] Jython 2.1 and JVM 1.3

Actually, 2.1 even seems to work with Java 1.4, which my previous version
(1.1 + 09) did not.
I've been using 1.3 for over a year now with JPython, and upgraded to 
Jython
2.1 a couple of weeks ago with no problems.

Bryn

> -----Original Message-----
> From:	bc...@wo... [SMTP:bc...@wo...]
> Sent:	Wednesday, July 11, 2001 3:34 PM
> To:	'jyt...@li...'
> Cc:	James Deller
> Subject:	Re: [Jython-dev] Jython 2.1 and JVM 1.3
>
> [James Deller]
>
> >Am interested in your Jython interpreter for possible use in an on-going 
> >project.  Is 2.1 compatible with JVM 1.3??  Haven't run across anything
> on
> >your site stating that it is..
>
> Well, I have not yet run across any thing that indicate jython-2.1a1
> isn't compatible with JDK1.3.
>
> You can safely assume it is compatible. If you discover a situation
> where it isn't, please report it as bug on our bug tracker:
>
>    http://sourceforge.net/tracker/?group_id=12867&atid=112867
>
> regards,
> finn
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/lists/listinfo/jython-dev

[Jython-dev] (no subject)

[Jojo G. <doi...@ya...>]

English, German, French, Spanish, Portuguese, Italian

THIS IS ONE TIME EMAIL!

You will NOT get further emails from sender, before You requested one.

You could translate pages and text behind the banners (if your email support
HTML coding) or links with Altavista below.

And now &  let's start to make some REAL MONEY!!

http://world.altavista.com/tr

http://ca.geocities.com/doitjustnow2001/
=====================

DIESES IST EIN ZEIT-CEmail! 

Erhalten Sie weitere email NICHT vom Absender, vor Ihnen forderte ein an. 
 
konnten Sie Seiten und Text hinter den Fahnen (wenn Ihre
emailst?tz-cHtml-Kodierung) oder den Links mit Altavista unten ?bersetzen. 

Und lassen Sie uns jetzt beginnen, etwas REALES GELD zu verdienen!!
  
http://world.altavista.com/tr 
 
http://ca.geocities.com/doitjustnow2001/
=====================

C'CEst UN EMAIL DE TEMPS!
Vous n'obtiendrez pas d'autres email de l'expediteur, avant vous a demande
un.<br> Vous froid traduisez les pages et le texte derri&egrave;re les
drapeaux (si votre codage de HTML de support d'email) ou des liens avec
Altavista ci-dessous.

Et maintenant commencons a faire une certaine VRAIE SOMME D'ARGENT!! 

http://world.altavista.com/tr 

http://ca.geocities.com/doitjustnow2001/
=====================

ESTE ES UN EMAIL DEL TIEMPO!
Usted no conseguira otros email de remitente, antes de usted solicito
uno.<br> Usted fr&iacute;o traduce las paginaciones y el texto detr&aacute;s
de las banderas (si su codificaci&oacute;n del HTML de la ayuda del email) o
de las conexiones con Altavista abajo.<p>
Y comencemos ahora a hacer un poco de DINERO VERDADERO!!  

http://world.altavista.com/tr 

http://ca.geocities.com/doitjustnow2001/
======================

ESTE E UM EMAIL DO TEMPO!
Voce nao comecara uns email mais adicionais do remetente, antes de voce pediu
um.<br>Voce frio traduz paginas e texto atras as bandeiras (de se seu coding
do HTML da sustentacao do email) ou as ligacoes com o Altavista abaixo. 

E agora let's come?ar fazer algum DINHEIRO REAL!!

http://world.altavista.com/tr

http://ca.geocities.com/doitjustnow2001/
=====================

CIO E UN EMAIL DI VOLTA!
Non otterrete ulteriori email dal trasmettitore, prima di voi ha chiesto
uno.<br>Freddo traducete le pagine e testo dietro le bandiere (se la vostra
codificazione del HTML di sostegno del email) o collegamenti con Altavista
qui sotto. 

Ed ora iniziamo a fare i certi SOLDI REALI!!

http://world.altavista.com/tr 

http://ca.geocities.com/doitjustnow2001/

[Jython-dev] (no subject)

[Jojo G. <doi...@ya...>]

English, German, French, Spanish, Portuguese, Italian

THIS IS ONE TIME EMAIL!

You will NOT get further emails from sender, before You requested one.

You could translate pages and text behind the banners (if your email support
HTML coding) or links with Altavista below.

And now &  let's start to make some REAL MONEY!!

http://world.altavista.com/tr

http://ca.geocities.com/doitjustnow2001/
=====================

DIESES IST EIN ZEIT-CEmail! 

Erhalten Sie weitere email NICHT vom Absender, vor Ihnen forderte ein an. 
 
konnten Sie Seiten und Text hinter den Fahnen (wenn Ihre
emailst?tz-cHtml-Kodierung) oder den Links mit Altavista unten ?bersetzen. 

Und lassen Sie uns jetzt beginnen, etwas REALES GELD zu verdienen!!
  
http://world.altavista.com/tr 
 
http://ca.geocities.com/doitjustnow2001/
=====================

C'CEst UN EMAIL DE TEMPS!
Vous n'obtiendrez pas d'autres email de l'expediteur, avant vous a demande
un.<br> Vous froid traduisez les pages et le texte derri&egrave;re les
drapeaux (si votre codage de HTML de support d'email) ou des liens avec
Altavista ci-dessous.

Et maintenant commencons a faire une certaine VRAIE SOMME D'ARGENT!! 

http://world.altavista.com/tr 

http://ca.geocities.com/doitjustnow2001/
=====================

ESTE ES UN EMAIL DEL TIEMPO!
Usted no conseguira otros email de remitente, antes de usted solicito
uno.<br> Usted fr&iacute;o traduce las paginaciones y el texto detr&aacute;s
de las banderas (si su codificaci&oacute;n del HTML de la ayuda del email) o
de las conexiones con Altavista abajo.<p>
Y comencemos ahora a hacer un poco de DINERO VERDADERO!!  

http://world.altavista.com/tr 

http://ca.geocities.com/doitjustnow2001/
======================

ESTE E UM EMAIL DO TEMPO!
Voce nao comecara uns email mais adicionais do remetente, antes de voce pediu
um.<br>Voce frio traduz paginas e texto atras as bandeiras (de se seu coding
do HTML da sustentacao do email) ou as ligacoes com o Altavista abaixo. 

E agora let's come?ar fazer algum DINHEIRO REAL!!

http://world.altavista.com/tr

http://ca.geocities.com/doitjustnow2001/
=====================

CIO E UN EMAIL DI VOLTA!
Non otterrete ulteriori email dal trasmettitore, prima di voi ha chiesto
uno.<br>Freddo traducete le pagine e testo dietro le bandiere (se la vostra
codificazione del HTML di sostegno del email) o collegamenti con Altavista
qui sotto. 

Ed ora iniziamo a fare i certi SOLDI REALI!!

http://world.altavista.com/tr 

http://ca.geocities.com/doitjustnow2001/

Re: [Jython-dev] jythonc with xml.sax

[Titus B. <ti...@ca...>]

-> In my situation, I can't use Xerces because it has a problem with the stuff
-> coming out of the SOAP server that I have no control of...
-> 
-> I'm talking about the d:\python21\lib\xml\sax
-> 
-> My program does:
-> import xml.sax 
-> 
-> or
-> 
-> import xml
-> from xml.sax 
-> 
-> both works from python, but when i try jythonc on it, even with --deep, it
-> won't pick up and build the xml.sax modules.

Oh!  I see.  The hazards of multilingual work ;).  Do both work from _jython_?

--t

RE: [Jython-dev] jythonc with xml.sax

[Gunadi, W. <Wiw...@co...>]

In my situation, I can't use Xerces because it has a problem with the stuff
coming out of the SOAP server that I have no control of...

I'm talking about the d:\python21\lib\xml\sax

My program does:
import xml.sax 

or

import xml
from xml.sax 

both works from python, but when i try jythonc on it, even with --deep, it
won't pick up and build the xml.sax modules.

Wiwih "Will" Gunadi
CGF Developer
972.577.0332
wiw...@co...
Compuware Corp. - Products



> -----Original Message-----
> From: Titus Brown [mailto:ti...@ca...]
> Sent: Monday, July 16, 2001 10:48 AM
> To: Gunadi, Wiwih
> Cc: 'jyt...@li...'
> Subject: Re: [Jython-dev] jythonc with xml.sax
> 
> 
> -> have any of you successfully compiled a program that 
> imports xml.sax ?
> -> i couldn't get the xml module to be created even when I 
> use --deep switch on
> -> jythonc
> 
> Yes, I did.  It was no fun, though; I'm almost glad to hear 
> that someone
> else is having problems ;).
> 
> In the end, I had to do two things:
> 
> * unpack and repack xerces.jar (I'm using Xerces-J 1 from 
> xml.apache.org);
> * include sax2.jar
> 
> I do not understand why either of these things was necessary, since
> things worked fine with the interpreter when I simply put xerces.jar
> in jre/lib/ext.  *shrug*
> 
> The package is GPL, and you can get the dist Makefile & JARs from CVS
> on Sourceforge.  Check out http://familjewels.sourceforge.net/.
> 
> cheers,
> --titus
>