From: Charlie G. <cha...@gm...> - 2007-04-25 08:48:36
|
Things are rolling along towards a second beta release. All of the patches and nearly all of the bugs for the release have been taken care of. Frank and I should knock out the last few bugs by the weekend. I'm also planning on committing my reworked java2py in the next few days to get that out there. The only issue about the release I'm still somewhat murky on is what to do about jythonc. With the additional usage beta1 saw, we got a fair number of reports about it breaking as regular Jython diverges from it. I think there were workarounds in the bug reports, but it still doesn't bode well. I feel like we should clearly mention that it's unmaintained and included only as a holdover until we completely replace it in 2.3. I really don't want any new users coming in to Jython to pick up on it and start using it. I don't like losing the features it provides, but we can't maintain it and we can't replace it before 2.3. Any problems with making it clearly deprecated? I'll probably add something to its readme, replace it with equivalent techniques everywhere I can on the site, and make a note of its decrepit status everywhere I can't outright replace it. In any case, it looks like beta 2 will come out in a couple weeks at Java One. I'd like to get a release candidate out a month after that, and then the final version two weeks after that. Charlie |
From: Paul D. F. <pdf...@ku...> - 2007-04-25 12:24:50
|
I'm using jythonc with a Jython version from about 2.2alpha with various workarounds. I think being able to package a Jython application into jar files somehow is very important and a strong selling point for Jython; however I think the way jythonc does this is overly complicated and prone to breakage, because it tries too hard to minimize disk footprint. What I found was most of the issues had to do with jythonc wanting to trace the imports a file uses and selectively include things into the resulting jar file. For example, I had to create a file as a workaround which forced the loading of all codecs to do character translation, since those are dynamically loaded at runtime, and so jythonc does not include them (since it only does a static analysis of imports). I also ran into problems where jythonc got into an endless loop chasing circular imports, and had to change jythonc itself to work around that. I also had problems where jythonc created code which would not load classes from jar files unless the jar files were present in the Java path jythonc used when it built everything. I've also just had general confusion trying to get Jython to do what I expected it to do -- resulting in part from trying to understand too many issues at once (classpath for jythonc; where my code was; bugs in jythonc; jythonc documentation; etc. all at once). Now that bandwidth and disk space are cheap, and testing remains expensive, it seems an approach ignoring the complexity of minimizing disk footprint might make a lot of sense. For example, one could have a standard large jar file which includes Jython and all the support libraries (perhaps with source, perhaps without), which is created once for each release. If you just want to run your own files from source (or even perhaps as $py.class (pyc equivalent) files), then you just need this one supporting jar which is easily downloaded. You never need to think about jythonc for such deployments. I'm not sure if jythonc would be needed for this; would a simpler build script suffice using regular Jython to compile the library files and then zip them all into a jar file? Then one could have a much more limited jythonc (and much easier to maintain one) which just packages up a directory of code into a jar file of just the compiled files somehow, and which assumes the availability of the first full Jython jar file. It would not need to do any fancy following of import dependencies -- it would just assume you had them all included. I'm not even sure you would need jythonc to do this -- perhaps you could just have regular Jython produce $py.class (pyc equivalent) files, and then zip them up yourself as a jar file? With this approach, you could deploy your applications in binary form with just two jar files, the entire Jython system jar, and then your compiled code jar (well, plus any other supporting jars you use). Probably it would also not be that hard to just append your compiled Jython files onto a standard Jython jar file using a standard zip file application if you really wanted just one jar file (like to run with "java -jar myjar.jar" -- and just ignore the issue of that jar file being larger than it needed to be (as you are including some libraries you aren't using). If people really care about tiny footprint, then they could just delete parts of the standard Jython jar file by hand and rebuild the jar/zip file, which seems a better default situation then forcing everyone else to worry about whether their application will work when they don't care about footprint. I would expect most people don't care too much about file size anymore, compared to convenience and reliability. I've seen these same sorts of runtime problems with Smalltalk systems that try to "strip" out functionality to minimize footprint of a deployed image; it almost never works right (certainly never the first few tries) given a dynamic language which may call code generated at runtime rather than statically; often these stripping features are just required for licensing reasons (like you are not allowed to ship the compiler, which is obviously not the case here). For example, jythonc as it is now seems to need you to include any dependent jar files when you compile otherwise it can't load them later as libraries. I'm surprised jythonc-produced systems have this limitation, since otherwise you can load arbitrary jars when you run Jython code from source (not under jythonc packaging); I am left wondering what it is about packaging or optimization that might require this, and if that really produces any significant value in the compiled result (compared to just including all base Jython functionality as a full library)? Perhaps if jythonc was just doing simpler things (without import chasing) these sorts of problems would go away? Is this idea of just having one standard full Jython system jar file plus extra user created jar files possibly the sort of approach people are thinking about for the future (or even for now)? Is there any fundamental reason it could not work (and with fairly minimal effort, possibly even now)? --Paul Fernhout Charlie Groves wrote: > The only issue about the release I'm still somewhat murky on is what > to do about jythonc. With the additional usage beta1 saw, we got a > fair number of reports about it breaking as regular Jython diverges > from it. I think there were workarounds in the bug reports, but it > still doesn't bode well. I feel like we should clearly mention that > it's unmaintained and included only as a holdover until we completely > replace it in 2.3. I really don't want any new users coming in to > Jython to pick up on it and start using it. I don't like losing the > features it provides, but we can't maintain it and we can't replace it > before 2.3. Any problems with making it clearly deprecated? I'll > probably add something to its readme, replace it with equivalent > techniques everywhere I can on the site, and make a note of its > decrepit status everywhere I can't outright replace it. |
From: Charlie G. <cha...@gm...> - 2007-04-25 18:31:38
|
On 4/25/07, Paul D. Fernhout <pdf...@ku...> wrote: > Is this idea of just having one standard full Jython system jar file > plus extra user created jar files possibly the sort of approach people > are thinking about for the future (or even for now)? Is there any > fundamental reason it could not work (and with fairly minimal effort, > possibly even now)? It already works as far as I know. The Jython installer has an option to make a full jar in your installation that includes the full standard lib of .py files. If you have .py files you've written on your classpath either as a directory or in a jar, they're importable. I committed a patch a few days ago to allow compileall.py from Python's stdlib to work, so when 2.2b2 is released you could use it to compile all of your .py files to .class files to be included in your built jar. It'd definitely be nice to actually show how to hook that up to ant or Maven, but other than that I think all of our ducks are in a row. Charlie |
From: Frank C. <fc...@pu...> - 2007-04-25 13:40:27
|
Is the JSR 223 stuff built so I can call a Jython script through the JSR 223 APIs? -Frank On Apr 25, 2007, at 1:48 AM, Charlie Groves wrote: > Things are rolling along towards a second beta release. All of the > patches and nearly all of the bugs for the release have been taken > care of. Frank and I should knock out the last few bugs by the > weekend. I'm also planning on committing my reworked java2py in the > next few days to get that out there. > > The only issue about the release I'm still somewhat murky on is what > to do about jythonc. With the additional usage beta1 saw, we got a > fair number of reports about it breaking as regular Jython diverges > from it. I think there were workarounds in the bug reports, but it > still doesn't bode well. I feel like we should clearly mention that > it's unmaintained and included only as a holdover until we completely > replace it in 2.3. I really don't want any new users coming in to > Jython to pick up on it and start using it. I don't like losing the > features it provides, but we can't maintain it and we can't replace it > before 2.3. Any problems with making it clearly deprecated? I'll > probably add something to its readme, replace it with equivalent > techniques everywhere I can on the site, and make a note of its > decrepit status everywhere I can't outright replace it. > > In any case, it looks like beta 2 will come out in a couple weeks at > Java One. I'd like to get a release candidate out a month after that, > and then the final version two weeks after that. > > Charlie > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > -- Frank Cohen, PushToTest, http://www.PushToTest.com, phone 408 374 7426 TestMaker: The open-source SOA test automation tool |
From: Kevin M. <km...@se...> - 2007-04-25 13:50:13
|
I'd be much interested in seeing what thet jythonc alternatives are. I had no clue it was deprecated and just recently put out the maven-jython-plugin, which relies on it. Currently, I tend to rely on just the .py -> .class generation. A viable alternative would be nice. I compensate for several of the other jythonc facilities via more mavenesque approaches, so they aren't as important. I imagine the ant task would be in a similar situation. In any event, I think it's important for the 2.2 release to have real tool support. If Jython is too much of a pain to add into an existing build system, it simply won't be adopted. That was precisely the problem I was up against here. -- Kevin Menard Servprise International WebReboot -- Remote Reboot Without Pulling the Plug 800.832.3823 On Wed, 25 Apr 2007 04:48:34 -0400, Charlie Groves <cha...@gm...> wrote: > Things are rolling along towards a second beta release. All of the > patches and nearly all of the bugs for the release have been taken > care of. Frank and I should knock out the last few bugs by the > weekend. I'm also planning on committing my reworked java2py in the > next few days to get that out there. > > The only issue about the release I'm still somewhat murky on is what > to do about jythonc. With the additional usage beta1 saw, we got a > fair number of reports about it breaking as regular Jython diverges > from it. I think there were workarounds in the bug reports, but it > still doesn't bode well. I feel like we should clearly mention that > it's unmaintained and included only as a holdover until we completely > replace it in 2.3. I really don't want any new users coming in to > Jython to pick up on it and start using it. I don't like losing the > features it provides, but we can't maintain it and we can't replace it > before 2.3. Any problems with making it clearly deprecated? I'll > probably add something to its readme, replace it with equivalent > techniques everywhere I can on the site, and make a note of its > decrepit status everywhere I can't outright replace it. > > In any case, it looks like beta 2 will come out in a couple weeks at > Java One. I'd like to get a release candidate out a month after that, > and then the final version two weeks after that. > > Charlie > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ |
From: Charlie G. <cha...@gm...> - 2007-04-25 18:23:34
|
What are you using jythonc for in the maven builder? It's only needed for three cases: running in a security manager that doesn't allow classes to be inserted dynamically(applets or restrictive servlets), subclassing Python in Java and referencing Python from Java through reflection. "Building" Jython should only require copying the .py files into wherever the Jar is built so they're available on the classloader and thereby sys.path for importation at runtime, so it should be really simple to hook it into a build system. Charlie On 4/25/07, Kevin Menard <km...@se...> wrote: > I'd be much interested in seeing what thet jythonc alternatives are. I > had no clue it was deprecated and just recently put out the > maven-jython-plugin, which relies on it. Currently, I tend to rely on > just the .py -> .class generation. A viable alternative would be nice. I > compensate for several of the other jythonc facilities via more mavenesque > approaches, so they aren't as important. I imagine the ant task would be > in a similar situation. > > In any event, I think it's important for the 2.2 release to have real tool > support. If Jython is too much of a pain to add into an existing build > system, it simply won't be adopted. That was precisely the problem I was > up against here. > > -- > Kevin Menard > Servprise International > WebReboot -- Remote Reboot Without Pulling the Plug > 800.832.3823 > > On Wed, 25 Apr 2007 04:48:34 -0400, Charlie Groves > <cha...@gm...> wrote: > > > Things are rolling along towards a second beta release. All of the > > patches and nearly all of the bugs for the release have been taken > > care of. Frank and I should knock out the last few bugs by the > > weekend. I'm also planning on committing my reworked java2py in the > > next few days to get that out there. > > > > The only issue about the release I'm still somewhat murky on is what > > to do about jythonc. With the additional usage beta1 saw, we got a > > fair number of reports about it breaking as regular Jython diverges > > from it. I think there were workarounds in the bug reports, but it > > still doesn't bode well. I feel like we should clearly mention that > > it's unmaintained and included only as a holdover until we completely > > replace it in 2.3. I really don't want any new users coming in to > > Jython to pick up on it and start using it. I don't like losing the > > features it provides, but we can't maintain it and we can't replace it > > before 2.3. Any problems with making it clearly deprecated? I'll > > probably add something to its readme, replace it with equivalent > > techniques everywhere I can on the site, and make a note of its > > decrepit status everywhere I can't outright replace it. > > > > In any case, it looks like beta 2 will come out in a couple weeks at > > Java One. I'd like to get a release candidate out a month after that, > > and then the final version two weeks after that. > > > > Charlie > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
From: Charlie G. <cha...@gm...> - 2007-04-25 18:15:51
|
https://scripting.dev.java.net/ contains code to hook Jython up to JSR 223. Charlie On 4/25/07, Frank Cohen <fc...@pu...> wrote: > Is the JSR 223 stuff built so I can call a Jython script through the > JSR 223 APIs? -Frank > > > > On Apr 25, 2007, at 1:48 AM, Charlie Groves wrote: > > > Things are rolling along towards a second beta release. All of the > > patches and nearly all of the bugs for the release have been taken > > care of. Frank and I should knock out the last few bugs by the > > weekend. I'm also planning on committing my reworked java2py in the > > next few days to get that out there. > > > > The only issue about the release I'm still somewhat murky on is what > > to do about jythonc. With the additional usage beta1 saw, we got a > > fair number of reports about it breaking as regular Jython diverges > > from it. I think there were workarounds in the bug reports, but it > > still doesn't bode well. I feel like we should clearly mention that > > it's unmaintained and included only as a holdover until we completely > > replace it in 2.3. I really don't want any new users coming in to > > Jython to pick up on it and start using it. I don't like losing the > > features it provides, but we can't maintain it and we can't replace it > > before 2.3. Any problems with making it clearly deprecated? I'll > > probably add something to its readme, replace it with equivalent > > techniques everywhere I can on the site, and make a note of its > > decrepit status everywhere I can't outright replace it. > > > > In any case, it looks like beta 2 will come out in a couple weeks at > > Java One. I'd like to get a release candidate out a month after that, > > and then the final version two weeks after that. > > > > Charlie > > > > ---------------------------------------------------------------------- > > --- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Jython-dev mailing list > > Jyt...@li... > > https://lists.sourceforge.net/lists/listinfo/jython-dev > > > > > > -- > Frank Cohen, PushToTest, http://www.PushToTest.com, phone 408 374 7426 > TestMaker: The open-source SOA test automation tool > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
From: Oti <oh...@gm...> - 2007-04-26 20:25:41
|
On 4/25/07, Charlie Groves <cha...@gm...> wrote: > https://scripting.dev.java.net/ contains code to hook Jython up to JSR 223. > > Charlie Yes, exactly. >From my point of view, it works like expected. I am going to show examples of using javax.script stuff during my talk at JavaOne. To be exact, I'll present a thin API on top of javax.script, as suggested by Clark Updike. The code will be publicly available by then. Best wishes, Oti. > On 4/25/07, Frank Cohen <fc...@pu...> wrote: > > Is the JSR 223 stuff built so I can call a Jython script through the > > JSR 223 APIs? -Frank |
From: Kevin M. <km...@se...> - 2007-04-25 18:45:17
|
On Wed, 25 Apr 2007 14:23:29 -0400, Charlie Groves = <cha...@gm...> wrote: > What are you using jythonc for in the maven builder? It's only needed= > for three cases: running in a security manager that doesn't allow > classes to be inserted dynamically(applets or restrictive servlets), > subclassing Python in Java and referencing Python from Java through > reflection. "Building" Jython should only require copying the .py > files into wherever the Jar is built so they're available on the > classloader and thereby sys.path for importation at runtime, so it > should be really simple to hook it into a build system. Perhaps I am going about it wrong. I'm using jythonc to compile Python = = classes to Java .class files that can be run directly from the JVM. For= = example, in one project I'm compiling a Jython file that uses a Java API= = and bundling it with the Jython class files into a standalone, executabl= e = JAR file. This file can run on any system with an appropriate JVM (>=3D= 1.4 = in this case), without requiring a local Jython installation. If there is a better approach to accomplishing this, I'd appreciate it. = = The general goal is to seemlessly weave Jython and Java classes together= . -- = Kevin Menard Servprise International WebReboot -- Remote Reboot Without Pulling the Plug 800.832.3823 |
From: Charlie G. <cha...@gm...> - 2007-04-25 20:21:45
|
On 4/25/07, Kevin Menard <km...@se...> wrote: > Perhaps I am going about it wrong. I'm using jythonc to compile Python > classes to Java .class files that can be run directly from the JVM. For > example, in one project I'm compiling a Jython file that uses a Java API > and bundling it with the Jython class files into a standalone, executable > JAR file. This file can run on any system with an appropriate JVM (>= 1.4 > in this case), without requiring a local Jython installation. What do you mean by a local Jython installation? As long as the jython classes are present, you can start up a PythonInterpreter and run Python code. The classes can be from a full jython install, jython.jar on your classpath, or by moving the jython classes into your jar. The only restrictions are that the classes are there and the security manager doesn't restrict byte code loading. > If there is a better approach to accomplishing this, I'd appreciate it. > The general goal is to seemlessly weave Jython and Java classes together. See http://wiki.python.org/jython/JythonMonthly/Articles/September2006/1 and http://wiki.python.org/jython/JythonMonthly/Articles/October2006/3 for examples of how to embed a PythonInterpreter and call Python code from Java. Charlie |
From: Kevin M. <km...@se...> - 2007-04-25 20:43:06
|
On Wed, 25 Apr 2007 16:21:42 -0400, Charlie Groves <cha...@gm...> wrote: > What do you mean by a local Jython installation? As long as the > jython classes are present, you can start up a PythonInterpreter and > run Python code. The classes can be from a full jython install, > jython.jar on your classpath, or by moving the jython classes into > your jar. The only restrictions are that the classes are there and > the security manager doesn't restrict byte code loading. This sounds to me like every application would require some amount of scaffolding code to get going. I want to use Jython as non-invasively as possible. Such scaffolding is a barrier to entry. With what I have now, I can simply type "mvn package", and what I get is a single JAR containing the Jython distribution plus my .py compiled as .class. The JAR manifest lists the compiled Jython file as the main class and there's no additional code necessary. > See http://wiki.python.org/jython/JythonMonthly/Articles/September2006/1 > and http://wiki.python.org/jython/JythonMonthly/Articles/October2006/3 > for examples of how to embed a PythonInterpreter and call Python code > from Java. I'll take a look at these and see if they provide an improvement over what I'm able to do with jythonc now. -- Kevin Menard Servprise International WebReboot -- Remote Reboot Without Pulling the Plug 800.832.3823 |
From: Charlie G. <cha...@gm...> - 2007-04-26 05:41:31
|
On 4/25/07, Kevin Menard <km...@se...> wrote: > On Wed, 25 Apr 2007 16:21:42 -0400, Charlie Groves > <cha...@gm...> wrote: > > > What do you mean by a local Jython installation? As long as the > > jython classes are present, you can start up a PythonInterpreter and > > run Python code. The classes can be from a full jython install, > > jython.jar on your classpath, or by moving the jython classes into > > your jar. The only restrictions are that the classes are there and > > the security manager doesn't restrict byte code loading. > > This sounds to me like every application would require some amount of > scaffolding code to get going. I want to use Jython as non-invasively as > possible. Such scaffolding is a barrier to entry. > > With what I have now, I can simply type "mvn package", and what I get is a > single JAR containing the Jython distribution plus my .py compiled as > .class. The JAR manifest lists the compiled Jython file as the main class > and there's no additional code necessary. Ahh, I misunderstood what you were trying to do. I can't think of any way to do that with the builtin code. You need something to setup a PythonInterpreter and to tell it what file to run. That code would be really simple though, so you could generate that source as part of your maven plugin. To remove the need to set things up like that, we could add a main method to the class files we make for .py files. That could handle making an interpreter and then telling it what to execute. I'll see if we can do something like that. Charlie |
From: Kevin M. <km...@se...> - 2007-04-26 11:56:02
|
On Thu, 26 Apr 2007 01:41:29 -0400, Charlie Groves = <cha...@gm...> wrote: > Ahh, I misunderstood what you were trying to do. I can't think of any= > way to do that with the builtin code. You need something to setup a > PythonInterpreter and to tell it what file to run. That code would be= > really simple though, so you could generate that source as part of > your maven plugin. True. I just like to hide magic code generation as much as possible. = Although, not a terrible solution. > To remove the need to set things up like that, we could add a main > method to the class files we make for .py files. That could handle > making an interpreter and then telling it what to execute. I'll see > if we can do something like that. This sounds interesting. Obviously you'll just want to make sure that y= ou = don't conflict with code that would execute in "main" anyway. = Particularly an "if __name__ =3D=3D '__main__'" check. Another option would be to provide a utility class that reads a value ou= t = of the manifest to execute. It's still a bit invasive, insomuch as one = = would not be able to seemlessly integrate the classes and it would only = = work from a JAR, but may strike a decent compromise. -- = Kevin Menard Servprise International WebReboot -- Remote Reboot Without Pulling the Plug 800.832.3823 |
From: Frank W. <fwi...@gm...> - 2007-04-26 13:29:40
|
On 4/26/07, Charlie Groves <cha...@gm...> wrote: > To remove the need to set things up like that, we could add a main > method to the class files we make for .py files. That could handle > making an interpreter and then telling it what to execute. I'll see > if we can do something like that. It would be cool if a main method in the .class files could make: java test$py just another way to say: jython test.py for the class: test$py.class provided the classpath included jython.jar Is that what you are thinking Charlie? -Frank |
From: Charlie G. <cha...@gm...> - 2007-04-26 16:14:41
|
On 4/26/07, Frank Wierzbicki <fwi...@gm...> wrote: > On 4/26/07, Charlie Groves <cha...@gm...> wrote: > > To remove the need to set things up like that, we could add a main > > method to the class files we make for .py files. That could handle > > making an interpreter and then telling it what to execute. I'll see > > if we can do something like that. > It would be cool if a main method in the .class files could make: > java test$py > > just another way to say: > jython test.py > > for the class: > test$py.class > > provided the classpath included jython.jar > > Is that what you are thinking Charlie? Yep. It turns out there's a method addMain in Module.java that does this, but it's been commented out since before Jython moved to CVS(at least 9 years ago). As such, it doesn't quite work any more but it looks like it shouldn't be too hard to hook it up before beta2. Charlie |
From: Frank W. <fwi...@gm...> - 2007-04-26 16:57:09
|
On 4/26/07, Charlie Groves <cha...@gm...> wrote: > Yep. It turns out there's a method addMain in Module.java that does > this, but it's been commented out since before Jython moved to CVS(at > least 9 years ago). As such, it doesn't quite work any more but it > looks like it shouldn't be too hard to hook it up before beta2. Cool. The only other use cases I can think of for jythonc (and these are probably ugly enough so we need to wait for the next release) is having a package for the $py.class files (in the Java sense) so for example, you could do: java com.whatever.module.test$py And we probably want to look at supporting some version of jythonc's "decoration" of Jython methods with Java signatures. (I think it only works in jythonc, I've really never used this feature of Jython, preferring to inherit from a Java interface if I need to call the Jython from Java). Again, these are things for post-2.2. -Frank |
From: Charlie G. <cha...@gm...> - 2007-04-28 21:58:52
|
On 4/26/07, Charlie Groves <cha...@gm...> wrote: > On 4/26/07, Frank Wierzbicki <fwi...@gm...> wrote: > > It would be cool if a main method in the .class files could make: > > java test$py > > > > just another way to say: > > jython test.py > > > > for the class: > > test$py.class > > > > provided the classpath included jython.jar > > > > Is that what you are thinking Charlie? > > Yep. It turns out there's a method addMain in Module.java that does > this, but it's been commented out since before Jython moved to CVS(at > least 9 years ago). As such, it doesn't quite work any more but it > looks like it shouldn't be too hard to hook it up before beta2. Ok, this is in. Compiled modules have a main method and are runnable from java. __name__ == '__main__' in the executed module so it's just like running a .py file with jython. It looks like imp.java was already creating class files with package qualified names, so the result of import test.regrtest is a class named test.regrtest$py. This means for Python code in packages you can use the normal Java package naming convention to run them from the java command or to add them to a jar's manifest. I think the best way to compile Jython class files for now is with the compileall.py script included in Lib. I added some code to py_compile.java to walk up the directory tree from where the .py file is being compiled and look for __init__.py files to make a fully qualified name for files created from compileall.py as well. compileall only handles writing compiled files out to the same directory as the source file, so something more advanced will be needed eventually, but it should work for now. |
From: Kevin M. <km...@se...> - 2007-04-26 17:15:20
|
On Thu, 26 Apr 2007 12:57:06 -0400, Frank Wierzbicki <fwi...@gm...> wrote: > Cool. The only other use cases I can think of for jythonc (and these > are probably ugly enough so we need to wait for the next release) is > having a package for the $py.class files (in the Java sense) so for > example, you could do: > > java com.whatever.module.test$py I actually rely on this a fair bit for the maven plugin. But, given that jythonc's support for this is a bit limited to begin with, I have to do some behind the scenes work to make it semi-usable. One thing for sure though is that dumping classes into the default package is problematic for a lot of applications. > And we probably want to look at supporting some version of jythonc's > "decoration" of Jython methods with Java signatures. (I think it only > works in jythonc, I've really never used this feature of Jython, > preferring to inherit from a Java interface if I need to call the > Jython from Java). I don't currently rely on any of this, but it's likely to be forthcoming in a future plugin release. I guess this would be mostly a facade to whatever tool is used anyway. > > Again, these are things for post-2.2. > Fair enough. What I got out of the roadmap though is that 2.3 is going to be a prolonged rewrite cycle. I still contend that simple tool support can go a long way in Jython adoption. So, maybe there's a balance between putting 2.2 off and waiting until 2.3 final to put out incremental improvements. -- Kevin Menard Servprise International WebReboot -- Remote Reboot Without Pulling the Plug 800.832.3823 |
From: Frank W. <fwi...@gm...> - 2007-04-26 17:35:16
|
On 4/26/07, Kevin Menard <km...@se...> wrote: > Fair enough. What I got out of the roadmap though is that 2.3 is going to > be a prolonged rewrite cycle. I still contend that simple tool support > can go a long way in Jython adoption. So, maybe there's a balance between > putting 2.2 off and waiting until 2.3 final to put out incremental > improvements. The focus of 2.3 will be cleanup, but we still want some improvements. For example, CPython 2.4 and 2.5 added features at a slow enough rate that we will be likely to ultimately target one of those for the final release. Also, since getting jythonc to work in its current form on >= 2.3 is problematic because of generators (they are difficult to implement in pure Java, but not so bad in bytecode due to the lack of goto in Java and its availability in bytecode). So jythonc work is definitely going to happen for the next release, there is only a question of how much. We absolutely do not want anything like the time span between 2.1 and 2.2 to happen again, so scope control is very important. -Frank |
From: Oti <oh...@gm...> - 2007-04-26 20:41:28
|
On 4/26/07, Charlie Groves <cha...@gm...> wrote: > On 4/26/07, Frank Wierzbicki <fwi...@gm...> wrote: > > On 4/26/07, Charlie Groves <cha...@gm...> wrote: > > > To remove the need to set things up like that, we could add a main > > > method to the class files we make for .py files. That could handle > > > making an interpreter and then telling it what to execute. I'll see > > > if we can do something like that. > > It would be cool if a main method in the .class files could make: > > java test$py > > > > just another way to say: > > jython test.py > > > > for the class: > > test$py.class > > > > provided the classpath included jython.jar > > > > Is that what you are thinking Charlie? > > Yep. It turns out there's a method addMain in Module.java that does > this, but it's been commented out since before Jython moved to CVS(at > least 9 years ago). As such, it doesn't quite work any more but it > looks like it shouldn't be too hard to hook it up before beta2. > > Charlie Do I understand it right: If the .py file has a if __name__ == __main__ section, it's $py.class file would have a corresponding public static void main(String args[]) method ? The longer I think about that, the cooler it appears to me. Oti. |
From: Frank W. <fwi...@gm...> - 2007-04-26 23:05:19
|
On 4/26/07, Oti <oh...@gm...> wrote: > Do I understand it right: If the .py file has a > if __name__ == __main__ > section, it's $py.class file would have a corresponding > public static void main(String args[]) > method ? > The longer I think about that, the cooler it appears to me. It would be more than that. Calling the .class file from java would run all of the python in the module, so for example a py file with only: print "hello" would get executed also. -Frank |