[reportlab-users] [Jython2.5.1] issue: Invalid method Code length 656615 + patch proposal

[Raphaël Valyi]

On Wed, Feb 10, 2010 at 1:03 PM, Andy Robinson <andy at reportlab.com> wrote:


> 2010/2/10 Raphaël Valyi <rvalyi at gmail.com>:

> > Hello guys,

> > I should say I'm sad to see that despite I provide you that trivial patch

> > one year ago on that mailing list

> > and you still did nothing for Jython,

>

> I cannot remember the reason why we didn't apply it, but there was

> one.  We probably misunderstood this as a bug in Jython which we

> thought would be fixed soon, or maybe we just got very busy with

> commercial projects, and none of us touch Java code in a normal month.

>  If this happens again just keep asking.

>


No trouble, this pretty much what we do now ;-)


>

>

> > despite even the clear failure of Unladen Swallow to save CPython (only

> 1.5

> > faster at best while using more memory;

>

> What, have they given up forever already?   All this means to me is

> that Guido, Tim and co did a pretty good job...

>


I rather call that a failure, but everybody can judge of course:
http://www.python.org/dev/peps/pep-3146/
As you see, pretty far from the 5x fanfare announcement at the start of the
project...
As for myself I'm pretty sure that if Jython got such a support it would
have done much better, in the same way JRuby emerges as
most performant Ruby implementation, leveraging the unparalleled VM
capabilities of the JVM.



> > If you want really good Jython support with decent performance,

>

>

> To be perfectly honest,  YOU want that.



If  that was only me, I could live with the patch, I'm actually trying to be
a bit more constructive...

We saw ZERO interest since

>


I can only be sad for you, sorry.

we did a 100% robust port in 2003.Every commercial customer we have

> is running CPython, we don't seek to employ Java skills, and we want

> to spend our time on new features and serving them.    Therefore,

> we'll try to handle patches as and when they are sent in, as long as

> we understand why, but we cannot make it a major focus.

>


Yeah, but keep in mind that by 2003, JRuby didn't proved the world yet that
a JVM backed
language could beat a C implementation hand down with a fraction of the
resources
(JRuby vs Ruby vs Rubinius). With he the recent JVM improvement (raw speed
perf) + invokedynamic stuff,
I only expect it to be better.

Now I agree, Jython is not yet JRuby, this is a momentum concern, it could
change in a way in or an other (Oracle
might very well bury it too; I do not expect them to be smart given how they
missed JRuby first).
But I mean when you need such a simple patch to give it a chance to happen,
may be you can just give that chance without thinking too much.



>

> Somebody will also need to update the _rl_accel.java we wrote, and

> check if our PIL-replacement-code still applies, to get halfway decent

> performance.

>


Well, this is much less important. First compatibility as it comes nearly
for free, then perf eventually.
The community could contribute it then I guess.
Also, Jython is now going to support CType extensions thanks to FFI. This is
the only standard I know
that it not tied to the CPython implementation (neither Java). In the future
if you have to select a way to interface with
native libs, please select that standard as it will result in a broader use
of your products.



> And if anyone is then using ReportLab in Jython successfully, tell us

> about it, or submit a case study or something!

>


I you make the patch standard, I promise we will report the success we have
with it.


>

>

> > I remind you the logic: because Jython will map each Python method to a

> Java

> > method and because by specification, the JVM is limited regarding to the

> > method size, we need Python programs to avoid methods that are too fat

> such

> > as the ones found in your fontdata.py file (a general good practice in

> > software engineering BTW).

>

> I agree that a code method above 64k would probably be a bit too long.

>  However, this is a single, static, in-memory singleton data structure

> which is key to our library, and we might need more of the same as we

> get more multilingual.  Failure to handle it is a weakness in Jython -

> but I agree we will work around it...

>

> - Andy

>


Yeah, this unfortunately isn't in the top priority list of Jython cause it
happens rarely, libs can
easily be fixed while on the contrary the fix in Jython wouldn't be trivial.

So that's very much appreciated if you could include this patch, reworking
it if you think it should
be reworked (I'm a Java/(J)Ruby programmer but admittedly still a poor
Python specialist).


Thanks in advance.

Raphaël Valyi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20100210/7358c8df/attachment-0001.htm>