Re: [netrexx-arb] Re: meetings for 3.02
Locked
Re: [netrexx-arb] Re: meetings for 3.02
 
|
René -
I am copying this response to the general NetRexx list because recent posts there suggest that some people do not realize that we are actively working on installer issues. I suggest that Tom also post his recent progress there. Now for some good news - I have solved the current NetRexx classloader issues described in my item #3 below. I changed the compiler module and the interpreter proxy-classloader to use the thread context classloader instead of the current classloader if they are loaded from the extensions directory. The NetRexx compiler can now load a Java compiler from the classpath and the NetRexx interpreter can now load classes from the classpath even if NetRexxC.jar is installed in the lib\ext directory! After I clean and document the changes, I will commit them to the experimental after3.01 branch on Kenai svn and update the pre-compiled jars on NetRexx-Plus also. There was an additional problem with Ant builds and the ecj compiler which I solved by passing the Ant task classloader to NetRexxC in the thread context classloader. This allows Ant NetRexx compiles to find a Java compiler from the Ant defined classpath even if NetRexxC.jar is in the lib\ext directory. The new compiler code uses reflection to call the Java compiler which is slightly more complex but has the advantage of removing any direct references to the compiler classes from the source. This should allow NetRexx to be built without having all referenced Java compilers present in the classpath. -- Kermit On 9/9/2012 10:55 AM, René Jansen wrote: > Hi Kermit, > > yes, got the message via the list. (1) Qua version number, I prepared trunk for 3.02 as there is some small fish to fry before we undertake bigger tasks that warrant a 4.0 - but of course this is for the ARB to decide. > > (2) I was just starting to look myself and preparing some test cases. An inventory is always a good idea. > > (3) I was planning to officially deprecate the ext directory because it is too much trouble. Still, if fixable, this problem should be fixed; but the problem still should be documented for the current versions. As I was planning the installer to be an important part of 3.02 (we have also obtained certificates for RexxLA now) it would be good to focus on this problem. > > best regards, > > René. > > On 9 sep. 2012, at 22:13, Kermit Kiser <[hidden email]> wrote: > >> Hi René - >> >> Let me know if this gets through on the list. Thanks for the welcome. I am currently living in Hawaii which is UTC-10. Most days are fairly open for me. >> >> As for agenda items, here is what I am interested in dealing with right now: >> >> 1) Are we actually working on 3.02 or on 4.00? In other words, do the currently pending enhancements merit a new version number or do we save that for significant changes to the language syntax itself? >> >> 2) Which enhancements from the current experimental branch (after3.01) should go into the next version? Do we need an inventory list of what is there? >> >> 3) I have been working on resolving a problem in NetRexxScript which occurs when NetRexxC.jar is installed in the Java extensions directory as some folks insist is correct. This environment causes the Java extensions classloader to load the NetRexxA interpreter which then creates a "proxy" classloader linked to that extensions classloader as parent. That classloader is higher in hierarchy than the system classloader so any class references in interpreted code to items not local and not in the extensions directory will fail. Nothing from the classpath can be accessed by interpreted code in this case as the system classloader which handles classpath is bypassed. Although this may not seem like a big problem to some people, it also affects the NetRexx compiler when it loads the Java compiler and hence it is a big problem for our future installer: If NetRexxC.jar is installed in the ext directory, the NetRexx compiler cannot find the Java compiler unless it is also installed in the ext directory. The classpath has no effect in this case - the tools.jar (or ecj-4.2.jar if used) must be copied to lib\ext also for NetRexxC to be able to load it. This conflict may be the cause of some of our more sticky installation problems. I am researching possible solutions but any ideas would be welcome. >> >> -- Kermit >> _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: [netrexx-arb] Re: meetings for 3.02
|
|
On 9/11/2012 2:18 PM, Kermit Kiser
wrote:
I suggest that Tom also post his recent progress there. Okay. I have treaded water during the ongoing installation discussion, but with this additional impetus I will <delurk/>. The current (alpha) incarnation of the NetRexx installer is built with IzPack (http://izpack.org/). Basic "construction" of the installer (which will be delivered as a standalone, executable JAR file) is "roughed in." That is, a jar file exists which, when double-clicked (to speak in Windows terms) will put down the directory structure and populate it with all the various bits and pieces of NetRexx, in either a default location or a location of the user's choosing. In order not to make it sound better than it is, it really isn't very different from a typical ZIP file -- indeed JARs are ZIPs and ZIPs are JARs -- and at least for the nonce it does nothing beyond put the NetRexx pieces on your computer. You can unzip an archive where it sits, or put the stuff somewhere else. Conceptually there is no difference. As the many posters have called out, getting down and dirty on each and every supported platform, twiddling the various bits in all the myriad ways to establish the PATH and CLASSPATH, etc. leads to a spaghetti bowl of complications, with twists and turns at every step. Examples are: Is Java already present? Is it the JRE or the JDK? Is it a supported version? Where is it? [Auxiliary questions might be: Is it Sun/Oracle/OpenJxx?] What is the operating system? What version? The list goes on (and on, and on, ...). Many of these issues have already been broached here on the list (none of them have been solved here, unfortunately). I am working on the installer project precisely for the reasons expressed by so many posters: I was frustrated with the pain and suffering that NetRexx installation was. I had moved to a new computer and managed to trip over my own feet trying to get it all to work again anew, just as so many of the group have mentioned (including the OP). I am no more qualified or knowledgeable than any other jamoke, but somebody has to do it, and I was stupid enough to stand still while everyone else took a step back <g>. An Open Source software project is a community effort, and not every job that needs to be done involves writing code: there are things like documentation, user's guides, troubleshooting tips, (ahem) installers ..., indeed everything that's already been mentioned (and more) is something anyone could pick up and run with. Head on over and "tweak the Wiki" (http://kenai.com/projects/netrexx/pages/Home)! Wikis are (as you know) freely editable by anyone. And there you have the NetRexx Installer Progress Report (with a bit of a rant tacked on). We (the guys on the other side of the glass) feel your pain, we are aware of most of the issues, and we are scratching our collective heads furiously to arrive at a satisfactory solution. I don't brag about it, but only because I don't have much to brag about at this point. Tom. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: [netrexx-arb] Re: meetings for 3.02
|
|
LOL! Thanks for the status update and the rant Tom. ;-)
In addition to an "attaboy", I wish to offer assistance if there is anything I can do to help. Can the code be published to svn (Kenai repository?) so that others may test and submit changes or enhancements? -- Kermit On 9/11/2012 10:35 AM, Tom Maynard
wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: [netrexx-arb] Re: meetings for 3.02
|
|
On 9/11/2012 4:20 PM, Kermit Kiser wrote:
> I wish to offer assistance if there is anything I can do to help. Well, my report was certainly never meant to be a cry for help ... but since you offer! :P At this point there really isn't anything much to do. I'm twiddling my thumbs a bit while the kinks are ironed out of a Windows certification issue (to avoid a nasty warning during Windows' installation). More helpful is your second query: > Can the code be published to svn (Kenai repository?) so that others > may test and submit changes or enhancements? And the answer is, "Of course it can!" Um, just not by me. Not because I'm unwilling, but because I've spent my last few years becoming a Git person, and (simultaneously) forgetting everything I knew about svn (which was pitifully little to begin with). Perhaps you'll recall when René mentioned Git recently my ears perked right up and I even decloaked to chime in with a +1, or some other supportive remark. Actually, all of this could not occur at a more inopportune time: we had some relatively severe water damage here at home over the weekend, and even as I type giant fans and dehumidifiers are roaring, some flooring is torn up, my wife is hiding out in the bedroom with a hot compress on her forehead, and we're about to pack up and skedaddle to a hotel for the duration while the restoration folk and contractors have their way with our place. While I will have my laptop in hand, I can't predict how much bandwidth I'll have or how productive I will be until about this time next week. However, I might be able to study up on svn a bit in the interim, with an eye to publishing the installer and beefing up my firewall for when the flames begin shooting in my direction -- all justly deserved criticism, I'm sure. In the meantime, I'll tuck your Attaboy under my pillow and draw whatever solace I can from that. Thanks, Kermit. Tom. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Tom Maynard
Thanks, Tom. I thought it was only me. Now I don't feel as stupid. Kenneth Klein
On 9/11/2012 2:18 PM, Kermit Kiser wrote: I suggest that Tom also post his recent progress there. Okay. I have treaded water during the ongoing installation discussion, but with this additional impetus I will <delurk/>. The current (alpha) incarnation of the NetRexx installer is built with IzPack (http://izpack.org/). Basic "construction" of the installer (which will be delivered as a standalone, executable JAR file) is "roughed in." That is, a jar file exists which, when double-clicked (to speak in Windows terms) will put down the directory structure and populate it with all the various bits and pieces of NetRexx, in either a default location or a location of the user's choosing. In order not to make it sound better than it is, it really isn't very different from a typical ZIP file -- indeed JARs are ZIPs and ZIPs are JARs -- and at least for the nonce it does nothing beyond put the NetRexx pieces on your computer. You can unzip an archive where it sits, or put the stuff somewhere else. Conceptually there is no difference. As the many posters have called out, getting down and dirty on each and every supported platform, twiddling the various bits in all the myriad ways to establish the PATH and CLASSPATH, etc. leads to a spaghetti bowl of complications, with twists and turns at every step. Examples are: Is Java already present? Is it the JRE or the JDK? Is it a supported version? Where is it? [Auxiliary questions might be: Is it Sun/Oracle/OpenJxx?] What is the operating system? What version? The list goes on (and on, and on, ...). Many of these issues have already been broached here on the list (none of them have been solved here, unfortunately). I am working on the installer project precisely for the reasons expressed by so many posters: I was frustrated with the pain and suffering that NetRexx installation was. I had moved to a new computer and managed to trip over my own feet trying to get it all to work again anew, just as so many of the group have mentioned (including the OP). I am no more qualified or knowledgeable than any other jamoke, but somebody has to do it, and I was stupid enough to stand still while everyone else took a step back <g>. An Open Source software project is a community effort, and not every job that needs to be done involves writing code: there are things like documentation, user's guides, troubleshooting tips, (ahem) installers ..., indeed everything that's already been mentioned (and more) is something anyone could pick up and run with. Head on over and "tweak the Wiki" (http://kenai.com/projects/netrexx/pages/Home)! Wikis are (as you know) freely editable by anyone. And there you have the NetRexx Installer Progress Report (with a bit of a rant tacked on). We (the guys on the other side of the glass) feel your pain, we are aware of most of the issues, and we are scratching our collective heads furiously to arrive at a satisfactory solution. I don't brag about it, but only because I don't have much to brag about at this point. Tom. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: [netrexx-arb] Re: meetings for 3.02
|
|
On 9/12/2012 8:13 AM,
[hidden email] wrote:
Thanks, Tom. I thought it was only me There are few mistakes that I haven't already made ... and (alas) few that I remember solving. I'm very familiar with the seeming impossibility of doing what should be a simple task (and that includes getting my eyes open most mornings <g>). You're not alone. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
In reply to this post by Kermit Kiser
Hi Kermit (now on Hawai, when mwemory does serve me right ;-)
A personal *big thank you* to you, personally, and Tom Maynard, of course, as well, and all others contributing for the continuous and *straight forward* efforts to put all the needed pieces together to let NetRexx become a real success... I'm currently still too busy with my own contributions (still on hold, but in my queue) to comment in detail, but would like to take this opportunity to thank everybody contributing to the further development & success of NetRexx! My (very personal) reason is very simple: *Any and all* of my Software is now written in NetRexx! Thomas. ======================================================================================== Am 11.09.2012 21:18, schrieb Kermit Kiser: > René - > > I am copying this response to the general NetRexx list because recent > posts there suggest that some people do not realize that we are > actively working on installer issues. I suggest that Tom also post his > recent progress there. > > Now for some good news - I have solved the current NetRexx classloader > issues described in my item #3 below. I changed the compiler module > and the interpreter proxy-classloader to use the thread context > classloader instead of the current classloader if they are loaded from > the extensions directory. The NetRexx compiler can now load a Java > compiler from the classpath and the NetRexx interpreter can now load > classes from the classpath even if NetRexxC.jar is installed in the > lib\ext directory! > > After I clean and document the changes, I will commit them to the > experimental after3.01 branch on Kenai svn and update the pre-compiled > jars on NetRexx-Plus also. > > There was an additional problem with Ant builds and the ecj compiler > which I solved by passing the Ant task classloader to NetRexxC in the > thread context classloader. This allows Ant NetRexx compiles to find a > Java compiler from the Ant defined classpath even if NetRexxC.jar is > in the lib\ext directory. > > The new compiler code uses reflection to call the Java compiler which > is slightly more complex but has the advantage of removing any direct > references to the compiler classes from the source. This should allow > NetRexx to be built without having all referenced Java compilers > present in the classpath. > > -- Kermit > > On 9/9/2012 10:55 AM, René Jansen wrote: >> Hi Kermit, >> >> yes, got the message via the list. (1) Qua version number, I prepared >> trunk for 3.02 as there is some small fish to fry before we undertake >> bigger tasks that warrant a 4.0 - but of course this is for the ARB >> to decide. >> >> (2) I was just starting to look myself and preparing some test cases. >> An inventory is always a good idea. >> >> (3) I was planning to officially deprecate the ext directory because >> it is too much trouble. Still, if fixable, this problem should be >> fixed; but the problem still should be documented for the current >> versions. As I was planning the installer to be an important part of >> 3.02 (we have also obtained certificates for RexxLA now) it would be >> good to focus on this problem. >> >> best regards, >> >> René. >> >> On 9 sep. 2012, at 22:13, Kermit Kiser <[hidden email]> wrote: >> >>> Hi René - >>> >>> Let me know if this gets through on the list. Thanks for the >>> welcome. I am currently living in Hawaii which is UTC-10. Most days >>> are fairly open for me. >>> >>> As for agenda items, here is what I am interested in dealing with >>> right now: >>> >>> 1) Are we actually working on 3.02 or on 4.00? In other words, do >>> the currently pending enhancements merit a new version number or do >>> we save that for significant changes to the language syntax itself? >>> >>> 2) Which enhancements from the current experimental branch >>> (after3.01) should go into the next version? Do we need an inventory >>> list of what is there? >>> >>> 3) I have been working on resolving a problem in NetRexxScript which >>> occurs when NetRexxC.jar is installed in the Java extensions >>> directory as some folks insist is correct. This environment causes >>> the Java extensions classloader to load the NetRexxA interpreter >>> which then creates a "proxy" classloader linked to that extensions >>> classloader as parent. That classloader is higher in hierarchy than >>> the system classloader so any class references in interpreted code >>> to items not local and not in the extensions directory will fail. >>> Nothing from the classpath can be accessed by interpreted code in >>> this case as the system classloader which handles classpath is >>> bypassed. Although this may not seem like a big problem to some >>> people, it also affects the NetRexx compiler when it loads the Java >>> compiler and hence it is a big problem for our future installer: If >>> NetRexxC.jar is installed in the ext directory, the NetRexx compiler >>> cannot find the Java compiler unless it is also installed in the ext >>> directory. The classpath has no effect in this case - the tools.jar >>> (or ecj-4.2.jar if used) must be copied to lib\ext also for NetRexxC >>> to be able to load it. This conflict may be the cause of some of our >>> more sticky installation problems. I am researching possible >>> solutions but any ideas would be welcome. >>> >>> -- Kermit >>> > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > -- Thomas Schneider CEO ThSITC IT Consulting KG Erdbergstr. 52-60/1/13 1030 Wien Austria, Europe Skype ID: Thomas.Schneider.Wien Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org) _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |