Menu
▾
▴
jython-dev
|
From: john c. <joh...@ya...> - 2001-08-03 02:58:50
|
I've been running Jython on j2sdk1.4.0beta. Haven't had any issues yet. Been writing an Acquisition Implicit module (in Jython, 30 lines of code). Next is to use the nio modules to create a medusa of sorts. I would really like to rewrite Zope to run on Java since java has true threads and a bunch of third party software (an really cool one that comes to mind EOF). I have a feeling that a Zope on Java would be far more appealing to consumers since now a whole universe of software is available Java and Jython have a wonderful interchangebly which is quite amazing. (another question which doesn't belong here) I would also like to change Zope such that it uses generators. The problem we are (or will be) running into is the large process size of the ZServers. Basically, every time one uses objectValues() the entire contents of the directory is loaded into memory and values placed into a list. I would like to skip zope 2.4.0 based on python 2.1 and go directly to 2.2a1 so that I could start this migration. The content management system will be pushing Zope to it limits. Use of memory has been rather cavalier in Zope world cause we think it is cheap and plentiful. However, reading 200,000 bulky objects into memory (magnified by 1000 users) is not ideal behavior when an iterator could be used instead and retrieve only one object at a time. Any thoughts or comments, please contact me. -john __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ |
|
From: Titus B. <ti...@ca...> - 2001-08-03 19:15:08
|
-> (another question which doesn't belong here) -> I would also like to change Zope such that it uses -> generators. The problem we are (or will be) running -> into is the large process size of the ZServers. -> Basically, every time one uses objectValues() the -> entire contents of the directory is loaded into memory -> and values placed into a list. I would like to skip -> zope 2.4.0 based on python 2.1 and go directly to -> 2.2a1 so that I could start this migration. The -> content management system will be pushing Zope to it -> limits. Use of memory has been rather cavalier in -> Zope world cause we think it is cheap and plentiful. -> However, reading 200,000 bulky objects into memory -> (magnified by 1000 users) is not ideal behavior when -> an iterator could be used instead and retrieve only -> one object at a time. A problem that I've been running into wrt Java is the JVM hard memory limit. Since users can (try to) load essentially arbitrary amounts of data into my GUI app, we need to set the maximum heap size of Java at an absurd place for *all* runs. I don't have comparisons yet -- someone has been thinking about rewriting various portions of my Jython app in wxPython -- but it seems to me like Jython and Java together are using outlandish amounts of memory. Something to think about wrt Zope... --t |
|
From: Andrew B. <ab...@fa...> - 2001-08-03 19:26:36
|
john coppola wrote: > I would really like to rewrite Zope to run on Java > since java has true threads and a bunch of third party > software (an really cool one that comes to mind EOF). > I have a feeling that a Zope on Java would be far more > appealing to consumers since now a whole universe of > software is available Java and Jython have a > wonderful interchangebly which is quite amazing. Interestingly, I attended the recent Washington, DC Zope/Python User's Group meeting and mentioned that I'm new to both Python (through Jython) and Zope. One of the guys from Digital Creations immediately piped up with "Great! You can do the Zope jython port!" When I quizzed him on whether there *was* a jython port, he smirked; they seemed to believe that it was a> unnecessary and b> very hard/impossible, a> because of their perception that Java is overhyped and slow and b> because of the complexity of the C code behind Zope. Isn't that what they said about the feasibility of implementing JPython, too? Andy Boyko ab...@fa... |
|
From: Titus B. <ti...@ca...> - 2001-08-03 19:32:35
|
-> Interestingly, I attended the recent Washington, DC Zope/Python -> User's Group meeting and mentioned that I'm new to both -> Python (through Jython) and Zope. One of the guys from -> Digital Creations immediately piped up with "Great! You -> can do the Zope jython port!" When I quizzed him on whether -> there *was* a jython port, he smirked; they seemed to believe -> that it was a> unnecessary and b> very hard/impossible, -> a> because of their perception that Java is overhyped and slow -> and b> because of the complexity of the C code behind Zope. I would have to agree with the "slow" comment, but Zope is hardly a prize-winning racecar either... of course, I doubt the Python class manipulation is going to get any faster in Jython! My understanding -- correct me if it differs from reality! -- is that Zope's C code is primarily in the area of medusa, their request-handling front-end. So, if you can figure out how to disentangle Zope from medusa, it shouldn't be too hard to whip up something that works. And, if you can do that, let me know, too, because I set out to do something like it a loong time ago, but within Python. I wanted to hook Zope up to PyWX, an embedding of Python in AOLserver, but failed. The frustration caused by the attempt comes through in my Zope Is Evil page (zope-is-evil-666.idyll.org)... -> Isn't that what they said about the feasibility of implementing -> JPython, too? Also see my "Zope is Evil" page for mild commentary about the smugness of Zopatistas ;). --titus |
|
From: Jeremy H. <je...@zo...> - 2001-08-03 20:31:36
|
>>>>> "TB" == Titus Brown <ti...@ca...> writes:
TB> that Zope's C code is primarily in the area of medusa, their
TB> request-handling front-end. So, if you can figure out how to
TB> disentangle Zope from medusa, it shouldn't be too hard to whip
TB> up something that works.
There is little or no C code in medusa. A quick scan of the Zope
source tree shows that C code is used in the following places:
- ExtensionClass and friends, which are used to implement
acquisition and a host of other things;
- BTrees, which are used to implement catalogs aka searches; and
- ZODB, which provides the persistence / transaction machinery.
There is also C code in access control, document templates, and the
PCGI wrapper. Zope also includes zlib and expat, which are
implemented in C.
In other words, C code provides several crucial features to Zope that
have nothing to do with the front-end.
The recent type-class unification work aims to extend the Python code
so that some (much?) of this C code is unnecessary, but I don't know
how long it will take to see that work folded back into Jython.
-> Isn't that what they said about the feasibility of implementing
-> JPython, too?
I recall Guido dismissing it as impossible, too.
TB> Also see my "Zope is Evil" page for mild commentary about the
TB> smugness of Zopatistas ;).
I'm sure you have plenty of legitimate technical criticisms of Zope.
"Evil" doesn't suggest to me what they are. It sounds more like name
calling to me, but perhaps I'm just smug.
Jeremy
|
|
From: Titus B. <ti...@ca...> - 2001-08-03 20:44:29
|
-> TB> that Zope's C code is primarily in the area of medusa, their -> TB> request-handling front-end. So, if you can figure out how to -> TB> disentangle Zope from medusa, it shouldn't be too hard to whip -> TB> up something that works. -> -> There is little or no C code in medusa. A quick scan of the Zope -> source tree shows that C code is used in the following places: Really? Oh, because asyncore has been integrated into the distribution, right? But it's not in Jython... for obvious reasons. -> - ExtensionClass and friends, which are used to implement -> acquisition and a host of other things; Ahh, this I didn't know about... -> - BTrees, which are used to implement catalogs aka searches; and Presumably this functionality could be replaced fairly easily with existing Java classes, no? -> - ZODB, which provides the persistence / transaction machinery. ZODB is (AFAIK) client/server, yes? -> There is also C code in access control, document templates, and the -> PCGI wrapper. Zope also includes zlib and expat, which are -> implemented in C. Wow. For zlib and expat, there are drop-in replacements; dunno how hard the rest would be. -> TB> Also see my "Zope is Evil" page for mild commentary about the -> TB> smugness of Zopatistas ;). -> -> I'm sure you have plenty of legitimate technical criticisms of Zope. -> "Evil" doesn't suggest to me what they are. It sounds more like name -> calling to me, but perhaps I'm just smug. ;) You should probably go read the page... Most of my criticisms are not, in fact, technical, but (at least wrt the state of documentation and the user community) were methodological. --t |
|
From: Jeremy H. <je...@zo...> - 2001-08-03 20:55:19
|
>>>>> "TB" == Titus Brown <ti...@ca...> writes: -> TB> that Zope's C code is primarily in the area of medusa, their -> TB> request-handling front-end. So, if you can figure out how to -> TB> disentangle Zope from medusa, it shouldn't be too hard to whip -> TB> up something that works. -> -> There is little or no C code in medusa. A quick scan of the Zope -> source tree shows that C code is used in the following places: TB> Really? Oh, because asyncore has been integrated into the TB> distribution, right? But it's not in Jython... for obvious TB> reasons. asyncore is implemented in Python on top of select. I'm not sure what C code you think is in there :-). -> - ExtensionClass and friends, which are used to implement -> acquisition and a host of other things; TB> Ahh, this I didn't know about... -> - BTrees, which are used to implement catalogs aka searches; and TB> Presumably this functionality could be replaced fairly easily TB> with existing Java classes, no? Probably not. The BTrees are persistence objects that interact with ZODB. -> - ZODB, which provides the persistence / transaction machinery. TB> ZODB is (AFAIK) client/server, yes? Not really. ZODB is a transactional persistence mechanism for Python. It needs to hook into the interpreter in a pretty low-level way to move objects in and out of memory. The only client-server part is ZEO, which is just one option from providing storage for the state of persistent objects. -> TB> Also see my "Zope is Evil" page for mild commentary about the -> TB> smugness of Zopatistas ;). -> -> I'm sure you have plenty of legitimate technical criticisms of Zope. -> "Evil" doesn't suggest to me what they are. It sounds more like name -> calling to me, but perhaps I'm just smug. TB> ;) You should probably go read the page... Most of my criticisms TB> ;are not, TB> in fact, technical, but (at least wrt the state of documentation TB> and the user community) were methodological. I just scanned your page. It's hard to follow all the stuff at the beginning. It seems basically polemical; there's no technical content or criticism that seems worth taking time to respond to. Jeremy |
|
From: Titus B. <ti...@ca...> - 2001-08-03 22:40:27
|
-> -> TB> that Zope's C code is primarily in the area of medusa, their -> -> TB> request-handling front-end. So, if you can figure out how to -> -> TB> disentangle Zope from medusa, it shouldn't be too hard to -> whip -> TB> up something that works. -> -> There is little or no C -> code in medusa. A quick scan of the Zope -> source tree shows that -> C code is used in the following places: -> -> TB> Really? Oh, because asyncore has been integrated into the -> TB> distribution, right? But it's not in Jython... for obvious -> TB> reasons. -> -> asyncore is implemented in Python on top of select. I'm not sure what -> C code you think is in there :-). Now I'm really confused! Some time ago (> 1 yr?) I seem to recall asyncore being compiled on my Zope install. I also remember that there was a separate page (from the Python docs) explaining what asyncore was -- this was back in the days of 1.5.2... Then, at the Python9 conference, someone told me that asyncore was a really good, low-level implementation that could not easily be beat in terms of performance. OK, well, looking around I see nothing that -> -> -> - ExtensionClass and friends, which are used to implement -> -> acquisition and a host of other things; -> -> TB> Ahh, this I didn't know about... -> -> -> - BTrees, which are used to implement catalogs aka searches; and -> -> TB> Presumably this functionality could be replaced fairly easily -> TB> with existing Java classes, no? -> -> Probably not. The BTrees are persistence objects that interact with -> ZODB. -> -> -> - ZODB, which provides the persistence / transaction machinery. -> -> TB> ZODB is (AFAIK) client/server, yes? -> -> Not really. ZODB is a transactional persistence mechanism for Python. -> It needs to hook into the interpreter in a pretty low-level way to -> move objects in and out of memory. The only client-server part is -> ZEO, which is just one option from providing storage for the state of -> persistent objects. -> -> -> TB> Also see my "Zope is Evil" page for mild commentary about the -> -> TB> smugness of Zopatistas ;). -> -> I'm sure you have plenty of -> legitimate technical criticisms of Zope. -> "Evil" doesn't suggest -> to me what they are. It sounds more like name -> calling to me, but -> perhaps I'm just smug. -> -> TB> ;) You should probably go read the page... Most of my criticisms -> TB> ;are not, -> TB> in fact, technical, but (at least wrt the state of documentation -> TB> and the user community) were methodological. -> -> I just scanned your page. It's hard to follow all the stuff at the -> beginning. It seems basically polemical; there's no technical content -> or criticism that seems worth taking time to respond to. -> -> Jeremy -> -> -> -> _______________________________________________ -> Jython-dev mailing list -> Jyt...@li... -> http://lists.sourceforge.net/lists/listinfo/jython-dev |
|
From: john c. <joh...@ya...> - 2001-08-03 23:54:01
|
> Now I'm really confused! Some time ago (> 1 yr?) I me too? As it turns out, the new j2sdk1.4.0 is capable of Non blocking IO. Once I create my medusa like interface wrappers i will benchmark it against the standard python asyncore package. However, I need not implement the asyncore module in Jython (python). Because the interchangeability of java and Jython classes as well as the ease of use of the Jython API, I can whip it up directly in Java with little time penality. We will soon see... The "jZope" project does necessarily have to be Zope, only Zope like with little incompatibilities. And for this, Acquisition is a must (just about done). The persistence mechanism is important but not necessary since other techniques such as 02R mappings are available. And as far as I know, java already has this stuff available (enterprise objects framework), thus porting to jZope is a piece of cake. (and all this due to the brilliant interchangeability of Java and Jython) The work done here is rather important believe it or not. Since jZope project could easily take advantage of all the DB connectivity software available to java. This team does not have to support any db connectivity software at all and focus on the reaaly cool stuff. __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ |
|
From: Ype K. <yk...@xs...> - 2001-08-04 18:42:54
|
John, <snip> > >As it turns out, the new j2sdk1.4.0 is capable of Non >blocking IO. Once I create my medusa like interface >wrappers i will benchmark it against the standard >python asyncore package. However, I need not >implement the asyncore module in Jython (python). >Because the interchangeability of java and Jython >classes as well as the ease of use of the Jython API, >I can whip it up directly in Java with little time >penality. > >We will soon see... <snip> Just in case you need sth to fall back onto from java 1.4 (...): http://softwaredev.earthweb.com/java/article/0,,12082_626271,00.html This is a java replacement for select(), they call it a Multiplexor, basically a single thread doing all the read()s and some sleep(). I hope you don't need this, Have fun, Ype |
|
From: Joseph G. <oc...@se...> - 2001-08-04 04:17:13
|
JZope (or Jope?) would be great and an obvious upgrade for zope, I believe. I think Jope should be an opportunity for a speed upgrade since Java is considerably faster than cpython. jpython is slow because it can not use java atomic (non-object) types for int's etc. The python spec'n would have to change to make that a possibility (at least while retaining 100% compatibility with cpython). Since this post, Zope Inc. has taken control of python development though, so they have the ability to change both zope and python now. There has also been some very recent discussion on ExtensionClass work that could relate to easing the port of zope to Java. So that could be one fewer hurdles which is good. It's also good since it may reflect some interest by Zope Inc. in the direction of a Jope. On the down side, Zope Inc. has repeatedly expressed the perception (even at the top levels) that Java is in *competitor* to Zope. Nonsense to me when the two technologies dovetail so nicely, but they perceive servlets and jsp as weak-kneed competition for zope. (Perhaps the ExtensionClass work is an indication of a change of heart?) In any case, the following quoted post is the meatiest overview of the challenges of porting to java that I've seen on the lists since becoming interested in zope a couple of years ago. Unfortunately, I haven't used it for over a year, so I'm no closer to understanding than the post itself, but you may find it useful. I would be interested in a jope or jzope. :-) = Joe = From: Joe Grace <oc...@se...> 11/3/99 12:12 PM Subject: Re: [Zope] Java Port CC: "zo...@zo..." <zo...@zo...> Awesome post. Thanks. And ouch. Sounds like heavy lifting. That bytecode stuff sounds sticky (hadn't even heard of that low a level of stuff before). I still think its an obvious win, but I can see where it may just be way hard. Something (for me) to strive for as I come up to speed with Zope. Thanks for the survey Phillip, = Joe = "Phillip J. Eby" wrote: > At 08:06 PM 11/2/99 -0800, Joe Grace wrote: > > > >Finally, on a coder side, there's been some discussion on this topic > >before. DC has reflected on the subject and pointed out some > >non-trivialities of porting to Java (mainly (?) C code). I imagine it's > >non-trivial, but getting something running might be reasonable. > > Actually, no, it isn't. The only part of Zope which might be 'reasonable' > is the ZPublisher bit, and even it makes heavy use of reflection (see > below). Here are just a few of the things I'm aware of: > > * Reflection: Zope makes heavy use of Python internals, such as function > metadata and examination of bytecodes used in Python expressions. These > are not available in JPython, and it's not even a C issue, just a Python > implementation issue. One reason some of these items don't exist in > JPython, is that JPython uses Java bytecodes, not Python bytecodes. > ZPublisher and DTML both use these reflection > > * ExtensionClasses: ZPublisher and DTML are the only parts of Zope that can > work without ExtensionClasses (and DTML performance suffers without the > MultiMapping extension). ExtensionClasses are C-based Python types which > override object behaviors in ways that Python objects cannot. This means > that porting them to JPython means altering the JPython Java skeletons - > which will require good understanding of JPython internals, as well as an > *extremely* good understanding of the intent of the original C implementation. > > * Persistence and synchronization: Zope object persistence and > synchronization are implemented via ExtensionClasses, and involve further > magic that will require very good understanding of the JPython skeletons as > well as the current C implementation for Zope. > > * Acquisition: Actually, not as difficult, compared to ExtensionClasses as > a whole and persistence in particular, but it's still ExtensionClass based > and probably a fair bit of work to do right. > > In short, if you want a "JZope", you're going to have to work mighty hard > for it. Or... if Pythons 1.6 through 2.0 move the ExtensionClass > machinery, or something like it, into the base definition of Python.. AND > the JPython folks follow suit... AND Digital Creations moves to the new > "standard" extension machinery, THEN... a JPython port might be (somewhat) > more "reasonable." > > I thought the idea was pretty cool myself a while back, until I started > thinking about what it would actually take. IMHO, it's too much work just > to get one extra buzzword added to Zope's already extensive collection of > them. :) |
|
From: Titus B. <ti...@ca...> - 2001-08-04 18:49:15
|
-> JZope (or Jope?) would be great and an obvious upgrade for zope, I believe. -> -> I think Jope should be an opportunity for a speed upgrade since Java is -> considerably faster than cpython. jpython is slow because it can not use -> java atomic (non-object) types for int's etc. The python spec'n would have -> to change to make that a possibility (at least while retaining 100% -> compatibility with cpython). Thanks for the meaty post, first of all -- that adds to the issues that Jeremy raised. I should note that one can now compile Java byte code to native machine code, via the GCJ front-end (a GCC family member). I don't know how much of a speedup this would give you, and, since my current app uses Swing, which doesn't have GCJ libs yet, I've not tested it out. On the other hand, as Jeremy Hylton pointed out, Zope uses a lot of C extension classes. Without some way to talk to them from Jython, you'd have to redo an awful lot of work, and it's clear that reimplementing them in Java would NOT lead to a speed increase ;). This is *separate* from all the bytecode issues... I asked the Webware creator, Chuck Esterbrook, if Webware used any C extension classes, and it turns out that it doesn't. So Webware could be a good candidate for "porting" to Jython, if people are interested in a complete OO Web framework. cheers, --titus |
