Down the JAVA trail
Locked
1234
1234
Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
 
|
Hi George, Mike, and all:
What would happen if we would make *NetRexx* C# compliant? Any thoughts ?? Thomas. ========================================================= Am 13.10.2010 17:53, schrieb Mike Cowlishaw:
--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
In reply to this post by David Requena
This is what I had in mind with the Eclipse NetRexx plugin. It has the
ability to have a single project with both Java and NetRexx source files which can inter-operate. Indeed, you can have Java and NetRexx edit windows (within the same project) side by side within the framework. Unfortunately I need the NetRexx source to straighten out a few rough edges, and the community needs to bring it up to date with the latest version of Java. Everyone is fed up with my endless complaints about the delay of the release of the source code, but the simple truth is that "it ain't gonna happen" until IBM and its RexxLA subsidiary decide to allocate the necessary resources to the job. Another problem is that apparently there is resistance to using Eclipse, but that is beyond my control. The best I can do is to try to develop the tool. Bill On 10/13/2010 11:53 AM, Mike Cowlishaw wrote: > George wrote: > > Mike, this was very helpful. I have one further issue for your consideration. My question about javac was prompted by a nebulous idea that has been on my mind; I would like to expound it in the hope that you will either encourage it or put it to rest. > > Some may have noticed that I harp on maintaining Java interoperability (though its existence right now seems to be in some doubt). This is partly because I feel that NetRexx has a natural constituency in programmers currently writing in Java (I assume that we all want NetRexx to spread and thrive in any and all directions). I am not saying that Java programmers are in any way to be preferred to others who might be attracted -- NetRexx should be a "big tent" -- just that they are "low hanging fruit". Further, non-Java programmers are not second class citizens in NetRexx. A vast category of programs can be written without ever (knowingly) invoking a Java class, and this will only improve if more Rexx features can be incorporated. And even those wishing to exploit the Java Class Library don't need to know the Java language per se, but just conventions used in describing and invoking the library. > > I made the switch to Java technology at a small software development firm which tried Java at the instigation of a talented, thoughtful and experienced programmer (not me). He did this by prototyping a system for a bid at a speed management had never seen. This won the bid and permission to form a group to fulfill the contract using Java. I jumped at the chance to join and was quickly won over (as was the company, which presently stipulated that all future development would be done in Java) by the speed and relative painlessness of java development. > > At about the same time I encountered NetRexx. I noticed it because of positive experiences with Rexx under OS/2 (I especially liked the Rexx- extensible editor). I vowed that if I ever returned to my preferred mode of employment, sole software cook and bottle washer for a scientific research group, NetRexx would be my development language. This eventually came to pass. > > I never even mentioned NetRexx to my employers as it was clearly a nonstarter from their standpoint. But I also had a blind spot: I thought of it as an either/or choice -- you either developed in NetRexx or in Java. But why not have mixed Java and NetRexx as an option? Then forward looking programmers in organizations using Java could go to their managers and say "I've found a language that improves the Java development process. It is totally interoperable with Java, but significantly simplifies coding. It has some powerful intrinsic features not present in Java, and as a bonus, reduces carpal tunnel syndrome. Furthermore you don't need to bet the farm on it. It can be introduced in small doses to the current code base while we gain confidence in it." In my dreams, time passes and one day a programmers asks "why not make NetRexx our standard language? We still have full access to our company library, it will reduce development costs and ..." Later, many more would their bosses "I've been reading about this NetRexx phenomenon and here's some UTube links. I know these people sound like fanatics but ..." > > Hence my original question about javac. I am not a computer scientist or language maven, but it seems to be, to a degree I only dimly understand, a guarantor of java compatibility. But to attract Java developers, we have to offer some kind of contract analogous in strength and clarity to "100% pure Java". I suppose we would also have to "keep up" with Java on certain source features in order to avoid deteriorating relations with Java programmers. This could be problematical considering that we have no control over Java's direction. > > Sorry for the long winded preamble. The bottom line -- I'd appreciate a candid assessment of these ideas. > > Hard to answer all that simply -- but yes I always thought as NetRexx having a place in a mixed Java/NetRexx environment. That was one major reason for NetRexxC having the ability to emit formatted and commented Java code. This meant that for managers who insisted that using NetRexx was too risky ('what if the language stops being developed") could be answered with "well at any time you can save the .java files and throw away the NetRexx and revert to being a 'pure Java' shop"). > > This also came in useful when I was working with Sun .. I could write decimal arithmetic algorithms in NetRexx and then ship the code in Java to the Sun engineers who didn't know NetRexx. Similarly the decimal class in the ICU4J package was required to be in Java -- but was written in NetRexx. (See http://speleotrove.com/decimal/decimalj/decimalj.html) > > Mike -------------------------------------------------------------------- mail2web.com - Microsoft® Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
Would it help you when you get access to my general Parser ?
Thomas. ========================================================= Am 13.10.2010 18:41, schrieb [hidden email]: > This is what I had in mind with the Eclipse NetRexx plugin. It has the > ability > to have a single project with both Java and NetRexx source files which can > inter-operate. Indeed, you can have Java and NetRexx edit windows (within > the > same project) side by side within the framework. > > Unfortunately I need the NetRexx source to straighten out a few rough > edges, and > the community needs to bring it up to date with the latest version of Java. > > Everyone is fed up with my endless complaints about the delay of the > release of > the source code, but the simple truth is that "it ain't gonna happen" until > IBM > and its RexxLA subsidiary decide to allocate the necessary resources to the > job. > > Another problem is that apparently there is resistance to using Eclipse, > but > that is beyond my control. The best I can do is to try to develop the tool. > > Bill > > On 10/13/2010 11:53 AM, Mike Cowlishaw wrote: >> George wrote: >> >> Mike, this was very helpful. I have one further issue for your > consideration. My question about javac was prompted by a nebulous idea > that has > been on my mind; I would like to expound it in the hope that you will > either > encourage it or put it to rest. >> Some may have noticed that I harp on maintaining Java interoperability > (though > its existence right now seems to be in some doubt). This is partly because > I > feel that NetRexx has a natural constituency in programmers currently > writing in > Java (I assume that we all want NetRexx to spread and thrive in any and all > directions). I am not saying that Java programmers are in any way to be > preferred to others who might be attracted -- NetRexx should be a "big > tent" -- > just that they are "low hanging fruit". Further, non-Java programmers are > not > second class citizens in NetRexx. A vast category of programs can be > written > without ever (knowingly) invoking a Java class, and this will only improve > if > more Rexx features can be incorporated. And even those wishing to exploit > the > Java Class Library don't need to know the Java language per se, but just > conventions used in describing and invoking the library. >> I made the switch to Java technology at a small software development firm > which tried Java at the instigation of a talented, thoughtful and > experienced > programmer (not me). He did this by prototyping a system for a bid at a > speed > management had never seen. This won the bid and permission to form a group > to > fulfill the contract using Java. I jumped at the chance to join and was > quickly > won over (as was the company, which presently stipulated that all future > development would be done in Java) by the speed and relative painlessness > of > java development. >> At about the same time I encountered NetRexx. I noticed it because of > positive experiences with Rexx under OS/2 (I especially liked the Rexx- > extensible editor). I vowed that if I ever returned to my preferred mode > of > employment, sole software cook and bottle washer for a scientific research > group, NetRexx would be my development language. This eventually came to > pass. >> I never even mentioned NetRexx to my employers as it was clearly a > nonstarter > from their standpoint. But I also had a blind spot: I thought of it as an > either/or choice -- you either developed in NetRexx or in Java. But why > not > have mixed Java and NetRexx as an option? Then forward looking programmers > in > organizations using Java could go to their managers and say "I've found a > language that improves the Java development process. It is totally > interoperable with Java, but significantly simplifies coding. It has some > powerful intrinsic features not present in Java, and as a bonus, reduces > carpal > tunnel syndrome. Furthermore you don't need to bet the farm on it. It can > be > introduced in small doses to the current code base while we gain confidence > in > it." In my dreams, time passes and one day a programmers asks "why not > make > NetRexx our standard language? We still have full access to our company > library, it will reduce development costs and ..." Later, many more would > their bosses "I've been reading about this NetRexx phenomenon and here's > some > UTube links. I know these people sound like fanatics but ..." >> Hence my original question about javac. I am not a computer scientist or > language maven, but it seems to be, to a degree I only dimly understand, a > guarantor of java compatibility. But to attract Java developers, we have > to > offer some kind of contract analogous in strength and clarity to "100% pure > Java". I suppose we would also have to "keep up" with Java on certain > source > features in order to avoid deteriorating relations with Java programmers. > This > could be problematical considering that we have no control over Java's > direction. >> Sorry for the long winded preamble. The bottom line -- I'd appreciate a > candid assessment of these ideas. >> >> Hard to answer all that simply -- but yes I always thought as NetRexx > having a > place in a mixed Java/NetRexx environment. That was one major reason for > NetRexxC having the ability to emit formatted and commented Java code. > This > meant that for managers who insisted that using NetRexx was too risky > ('what if > the language stops being developed") could be answered with "well at any > time > you can save the .java files and throw away the NetRexx and revert to being > a > 'pure Java' shop"). >> >> This also came in useful when I was working with Sun .. I could write > decimal > arithmetic algorithms in NetRexx and then ship the code in Java to the Sun > engineers who didn't know NetRexx. Similarly the decimal class in the > ICU4J > package was required to be in Java -- but was written in NetRexx. (See > http://speleotrove.com/decimal/decimalj/decimalj.html) >> >> Mike > > -------------------------------------------------------------------- > mail2web.com - Microsoft® Exchange solutions from a leading provider - > http://link.mail2web.com/Business/Exchange > > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > -- Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
In reply to this post by Thomas.Schneider.Wien
On 13 October 2010 09:35, Thomas Schneider <[hidden email]> wrote: And make it platform specific; why? Not everyone in this community Windows. That's the beauty and appeal of the JVM.
Alan. -- Can't tweet, won't tweet! _______________________________________________ Ibm-netrexx mailing list [hidden email]
Alan
-- Needs more cowbell. |
|
|
In reply to this post by billfen
On 13 okt 2010, at 18:41, [hidden email] wrote: > This is what I had in mind with the Eclipse NetRexx plugin. It has the > ability > to have a single project with both Java and NetRexx source files which can > inter-operate. Indeed, you can have Java and NetRexx edit windows (within > the > same project) side by side within the framework. Bill, I think the Eclipse support is very important. Please keep at it the best you can. best regards, René Jansen. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
In reply to this post by Mike Cowlishaw
Mike Cowlishaw schrieb am 13.10.2010 17:53:
> Hard to answer all that simply -- but yes I always thought as NetRexx > having a place in a mixed Java/NetRexx environment. That was one major > reason for NetRexxC having the ability to emit formatted and commented > Java code. This meant that for managers who insisted that using NetRexx > was too risky ('what if the language stops being developed") could be > answered with "well at any time you can save the .java files and throw > away the NetRexx and revert to being a 'pure Java' shop"). > This also came in useful when I was working with Sun .. I could write > decimal arithmetic algorithms in NetRexx and then ship the code in Java > to the Sun engineers who didn't know NetRexx. Similarly the decimal > class in the ICU4J package was required to be in Java -- but was written > in NetRexx. (See http://speleotrove.com/decimal/decimalj/decimalj.html) > Mike Hi Mike, I have to intercede here. It *is* possible to code like you highlighted above, but having NetRexx and Java mixed in a project can be quite tricky. You always have to be very cautious not to have dependencies which lock you out from compiling the whole thing. Our framework, which is a few hundred thousand lines of NetRexx alone, is a mixed one and includes Groovy, NetRexx and Java altogether. But sometimes I wish NetRexx had this wonderful "stubs" generation feature of Groovy to resolve dependencies completely on its own, so generating a No-op Java program without any 'meat', just non-private methods and properties purely created to make Java files around it compile with javac, and then having NetRexxC compile it's breed. That would really solve quite some headaches sometimes :-) Bottom line is: be careful to tell you can mix NetRexx and Java. It's interoperable, but not mixable. -- cu, Patric _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
In reply to this post by Thomas.Schneider.Wien
Thomas,
In addition to Android support by Kermit there is also jailbreaked iphone b y René and BlackBerry by me. BlackBerry runtime classes support won't be distributable until NetRexx itself gets open sourced. NetRexx development withouth Rexx type, parse, trace and friends is available if anyone interested. Also porting the BB stuff to J2ME would be trivial. That would bring Symbian onto the family me thinks :-) - Saludos / Kind regards, David Requena -----Original Message----- From: Thomas Schneider <[hidden email]> Sender: [hidden email] Date: Wed, 13 Oct 2010 15:32:46 To: IBM Netrexx<[hidden email]> Reply-To: [hidden email], IBM Netrexx <[hidden email]> Subject: Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail) Hi Rene, so good to hear from you.... Let me repeat the reason (*my reason*) *why* we should use www.KENAI.com *and not* SourceForge for the open source release of Netrexx: 1.) SourceForge holds any kinds of projects. 2.) www.KENAI.com holds *only Java related* projects. 3.) When putting NetRexx to www.KENAI.com, we can easily *exploit* both it's language recognition to a very broad user base.... As you probably know, Kermit Kiser has already developped a method to run NetRexx Programs on an ANDROID smart phone.... I got and tested it -- without any problems -- on my RED BULL HUAWEI Handy ! This would mean, that we can use NetRexx as a language to program ANDROID handys.... Thinks about the portential market: Google sells some 60.000 (sixty thousand) ANDROID licences *by day* By day!!! :-) ... and, if I am reading everything correct, the Goosle CHROME OS is coming out soon, which will be again Java based, as far as I do know. Now, think about a language which is able to cater the whole span from a smart phone to IBM zOS (whithout any re-compilation necessary) Maybe that's the future of Netrexx we should think about! Human oriented for human beeings... Thomas. ============================================================== Am 13.10.2010 15:05, schrieb René Jansen: > Tom, > > for your information, ooRexx also has discussion groups that are open to everyone that registers, at SourceForge. > > best regards, > > René. > > On 13 okt 2010, at 14:54, Thomas Schneider wrote: > >> Hello Chip, >> thanks for the insights.... >> >> I am offering, again, to help in the NetRexx Project as far as I can. >> >> I'm fascinated from the language design, and willing to support it (as I'm already in pension). >> >> I think, however, that ooRexx and NetRexx discussions should be splitted, >> having an OWN NetRexx group, which I think should be OPEN. >> >> Also, putting the OPEN source of NetRexx on www.KENAI.com would give NetRexx an instant *visibility* to the Java minded people. As far as I can remember, some 50.000 very knowledgable individuals/companies are a member of www.KENAI.com with various Java related projects. >> >> Far more, as any *own NetRexx* activity can build up quickly.... >> >> As far as I got the rules, www.KENAI.com has a very excelennt *standard* >> Project scheme we could simply re-use, thus avoiding all the hassles >> to build everything up again from scratch ... >> >> Comments will be welcome... :-) >> >> Thomas Schneider. >> ============================================================= >> >> Am 11.10.2010 00:27, schrieb Chip Davis: >>> On 10/10/10 19:12 [hidden email] said: >>>> The slides for Virgil Hein's presentation at the May, 2009 RexxLA Symposium >>>> are available on the web. These slides are (in theory) for RexxLA members >>>> only, but they are readily accessible >>> The RexxLA policy is that Rexx Symposium materials are exclusively available to RexxLA members for one year after the Symposium in which they were presented. After that time, they are available to everyone. >>> >>>> It appears to me that the quid pro quo is that IBM provides the source to >>>> RexxLA, and RexxLA must provide a plan to administer the open source (and >>>> of course follow through on that plan). >>> And you would be correct. But that quid pro quo is not negotiable, and as RexxLA is a non-profit organization and René is an unpaid officer, it would be hard to tease out a conflict of interest there. In fact, one could easily argue that his interest, expertise, and current IBM employment are advantages. >>> >>>> The only reasonable conclusion I >>>> can think of is that RexxLA has not yet provided a satisfactory plan or is >>>> unable to commit the resources to administer it. >>> Well, reasonableness tends to be a very subjective measure. From what I understand (and I am not privy to any more than anyone else, see Virgil's presentation) RexxLA has committed in writing to a plan that meets IBM's objectives, and to providing the resources necessary to execute that plan. Had that not been the case, our application would not have made it this far. >>> >>>> Based on the OORexx >>>> support, it is obviously a lot of work. >>> True. We knew that from the outset, but the opportunity was too good to pass up. Besides, the alternative (letting Object REXX languish in obscurity in an IBM-proprietary vault) was unacceptable to many of us. >>> >>>> Another possibility is that IBM >>>> has actually changed its mind and is trying to renege on the commitment to >>>> open source, but I seriously doubt that is the case. >>> To conclude that IBM has decided to renege on the arrangement would be to assume that something had changed and that they were not telling us of their decision for some reason. (They don't want to hurt our feelings?) It's always quicker and easier to say "No". It's much more difficult and time-consuming to work through all the problems so you can say "Yes". >>> >>> Consider that IBM, like nearly every other company in this economy, is having to do more with less. I know that most of my IBM contacts are now also doing the work of two or three of their colleagues who are no longer IBM employees. As has been noted, a pro-bono project such as this cannot have a high priority in such an environment. >>> >>>> It is unfortunate that there was no RexxLA Symposium in 2010 to tell the >>>> world (or at least the members :) what progress was made. Outsiders can >>>> only speculate on what has and has not been done in the year and a half >>>> since the 2009 Symposium. >>> If by "outsiders" you mean "those who have not signed that NDA", I doubt that there would have been much that could have been legally shared. As for their speculations, in the absence of knowledge one way or the other, I tend to seek the counsel of Friar Ockham. >>> >>> Yes, it is a shame that we were able to string together only 20 years worth of Rexx Symposiums. It was also miracle that we did. Everyone wants to be a guest; only the truly selfless volunteer to host. >>> >>> -Chip- >>> >>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> >>> >> >> -- >> Thomas Schneider Projects ReyC& LOGOS on www.KENAI.com >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > -- Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com _______________________________________________ Ibm-netrexx mailing list [hidden email] _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
In reply to this post by Patric Bechtel-2
I've mixed Java and NetRexx quite often without any problem as long as I had java clases dependent on NetRexx classes or the other way around. Never both at the same time. - Saludos / Kind regards, David Requena -----Original Message----- From: Patric Bechtel <[hidden email]> Sender: [hidden email] Date: Wed, 13 Oct 2010 19:29:21 To: IBM Netrexx<[hidden email]> Reply-To: [hidden email], IBM Netrexx <[hidden email]> Subject: Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail) Mike Cowlishaw schrieb am 13.10.2010 17:53: > Hard to answer all that simply -- but yes I always thought as NetRexx > having a place in a mixed Java/NetRexx environment. That was one major > reason for NetRexxC having the ability to emit formatted and commented > Java code. This meant that for managers who insisted that using NetRexx > was too risky ('what if the language stops being developed") could be > answered with "well at any time you can save the .java files and throw > away the NetRexx and revert to being a 'pure Java' shop"). > This also came in useful when I was working with Sun .. I could write > decimal arithmetic algorithms in NetRexx and then ship the code in Java > to the Sun engineers who didn't know NetRexx. Similarly the decimal > class in the ICU4J package was required to be in Java -- but was written > in NetRexx. (See http://speleotrove.com/decimal/decimalj/decimalj.html) > Mike Hi Mike, I have to intercede here. It *is* possible to code like you highlighted above, but having NetRexx and Java mixed in a project can be quite tricky. You always have to be very cautious not to have dependencies which lock you out from compiling the whole thing. Our framework, which is a few hundred thousand lines of NetRexx alone, is a mixed one and includes Groovy, NetRexx and Java altogether. But sometimes I wish NetRexx had this wonderful "stubs" generation feature of Groovy to resolve dependencies completely on its own, so generating a No-op Java program without any 'meat', just non-private methods and properties purely created to make Java files around it compile with javac, and then having NetRexxC compile it's breed. That would really solve quite some headaches sometimes :-) Bottom line is: be careful to tell you can mix NetRexx and Java. It's interoperable, but not mixable. -- cu, Patric _______________________________________________ Ibm-netrexx mailing list [hidden email] _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
True. We had both at the same time, and it was fine as long as the makefile did specify the right dependency graphs. We did these by hand. It must be possible to build in what javac does, and I have toyed with Jikes, that has an option to display dependencies. I remember someone building a compilation shell for NetRexx that did resolve dependencies the right way; I must have it somewhere.
Every dependency cycle can be broken with interface classes, however. best regards, René. On 13 okt 2010, at 20:15, David Requena wrote: > > I've mixed Java and NetRexx quite often without any problem as long as I had java clases dependent on NetRexx classes or the other way around. Never both at the same time. > > - > Saludos / Kind regards, > David Requena > > -----Original Message----- > From: Patric Bechtel <[hidden email]> > Sender: [hidden email] > Date: Wed, 13 Oct 2010 19:29:21 > To: IBM Netrexx<[hidden email]> > Reply-To: [hidden email], IBM Netrexx <[hidden email]> > Subject: Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail) > > Mike Cowlishaw schrieb am 13.10.2010 17:53: >> Hard to answer all that simply -- but yes I always thought as NetRexx >> having a place in a mixed Java/NetRexx environment. That was one major >> reason for NetRexxC having the ability to emit formatted and commented >> Java code. This meant that for managers who insisted that using NetRexx >> was too risky ('what if the language stops being developed") could be >> answered with "well at any time you can save the .java files and throw >> away the NetRexx and revert to being a 'pure Java' shop"). >> This also came in useful when I was working with Sun .. I could write >> decimal arithmetic algorithms in NetRexx and then ship the code in Java >> to the Sun engineers who didn't know NetRexx. Similarly the decimal >> class in the ICU4J package was required to be in Java -- but was written >> in NetRexx. (See http://speleotrove.com/decimal/decimalj/decimalj.html) >> Mike > > Hi Mike, > > I have to intercede here. It *is* possible to code like you highlighted > above, but having NetRexx and Java mixed in a project can be quite tricky. > You always have to be very cautious not to have dependencies which lock > you out from compiling the whole thing. > Our framework, which is a few hundred thousand lines of NetRexx alone, > is a mixed one and includes Groovy, NetRexx and Java altogether. But > sometimes I wish NetRexx had this wonderful "stubs" generation feature > of Groovy to resolve dependencies completely on its own, so generating a > No-op Java program without any 'meat', just non-private methods and > properties purely created to make Java files around it compile with > javac, and then having NetRexxC compile it's breed. That would really > solve quite some headaches sometimes :-) > > Bottom line is: be careful to tell you can mix NetRexx and Java. It's > interoperable, but not mixable. > > -- > cu, Patric > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
RE: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
In reply to this post by Patric Bechtel-2
Hi Patric,
> I have to intercede here. It *is* possible to code like you > highlighted above, but having NetRexx and Java mixed in a > project can be quite tricky. > You always have to be very cautious not to have dependencies > which lock you out from compiling the whole thing. > Our framework, which is a few hundred thousand lines of > NetRexx alone, is a mixed one and includes Groovy, NetRexx > and Java altogether. But sometimes I wish NetRexx had this > wonderful "stubs" generation feature of Groovy to resolve > dependencies completely on its own, so generating a No-op > Java program without any 'meat', just non-private methods and > properties purely created to make Java files around it > compile with javac, and then having NetRexxC compile it's > breed. That would really solve quite some headaches sometimes :-) No reason why not to add that to NetRexx :-). In fact probably almost trivial to effect -- just a 'skip phase 3' option in the compiler and a test or two in the main generator loop. > Bottom line is: be careful to tell you can mix NetRexx and > Java. It's interoperable, but not mixable. Umm, since you can emit Java code from the NetRexx, then throw away the NetRexx source -- you now have a purely Java project. Cannot get much more mixable than all the same language, surely? Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
Hi Mike,
Mike Cowlishaw schrieb am 13.10.2010 20:48: > No reason why not to add that to NetRexx :-). In fact probably almost trivial > to effect -- just a 'skip phase 3' option in the compiler and a test or two in > the main generator loop. Sounds too good to be true. I'm looking forward playing with the source to get that working ASAP. Would be a real time saver, really. >> Bottom line is: be careful to tell you can mix NetRexx and >> Java. It's interoperable, but not mixable. > > Umm, since you can emit Java code from the NetRexx, then throw away the NetRexx > source -- you now have a purely Java project. Cannot get much more mixable than > all the same language, surely? As I said: As long as you can get your dependencies worked out, it's that way. But in the worst of cases, you cannot generate Java code because NetRexx insists on having a Java class compiled first, which itself might depend on NetRexx generating a Java file first. And believe me, I'm not constructing that. So having the stubs option would solve these cases almost completely. -- cu, Patric _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
In reply to this post by Mike Cowlishaw
I'm embarrassed to admit that I've never looked at that form of Java source let alone wondered why it existed (it sounded like pretty printing) -- for obvious reasons I've focused on the version that corellates one to one with the NetRexx source. But I see now that it too is an important guarantor of safety: no future NetRexx development can rob you of what you have already produced, a strong promise indeed. Such "talking points" should feature prominently in the NetRexx relaunch press release when it is written.
On Wed, Oct 13, 2010 at 11:53 AM, Mike Cowlishaw <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
In reply to this post by Patric Bechtel-2
While I was writing my last post, this thread exploded. This is the "meatiest" discussion I can remember. Don't stop!
On Wed, Oct 13, 2010 at 3:10 PM, Patric Bechtel <[hidden email]> wrote: Hi Mike, _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by Thomas.Schneider.Wien
Thomas,
You said "I think, however, that ooRexx and NetRexx discussions should be splitted, having an OWN NetRexx group, which I think should be OPEN." I went back through the RexxLA discussion list archives for the past two months. Out of 441 postings, I counted exactly three postings that had anything to do with NetRexx. One was yours (an egregiously cross-posted ad for your company). The other was an apparently mis-directed question by Bob H. regarding the status of NetRexxDE, and the response by David R. That's it. You are a RexxLA member. Can you not see that for all intents and purposes, all the NetRexx discussion is occurring on netrexx.org? How much more "splitted" could the ooRexx and NetRexx discussion lists be? And how much more OPEN could this list (our OWN ibm-netrexx) be? As René pointed out, there are OPEN discussion lists available to ooRexx users, hosted by Sourceforge, and dutifully followed by the ooRexx Project Team. For whatever reason, there is very little traffic on them. My conclusion is that is because those who are most interested in ooRexx are, or became, RexxLA members in order to avail themselves of the community and expertise available there. As for your espousal of Kenai.com, don't you think that the choice of a site for the NetRexx source code repository should be a decision made by the Project Team? While you seem enamored of Project Kenai, others might balk at its 'beta' status or its association with Oracle. I would rather leave that discussion and decision to the people who will be working most closely with the code. For many reasons, they may prefer Sourceforge or any of a number of alternate source code repositories. I won't defend Sourceforge; I find it to be a bloody mess to use, with a hopelessly non-intuitive user interface. The easy way to download ooRexx is to go to oorexx.org which has a much simpler user interface to what you need on Sourceforge. It appears that the ooRexx team has reduced its dependence on SF to the bare minimum of being an SVN server/tracker and discussion listserver. Most the package builds are being done on a box in David Ashley's bedroom/office. This seems to provide much better control. The fact that Kenai hosts only Java-related projects is a double-edged sword. Sure, it will be instantly visible to the Java-cognoscenti: folks who are already on the Java bandwagon and who are the least likely to be looking for an "easy Java" language processor. They are not our audience. We need to target those who looked at Java some time ago and concluded that it was too complicated, convoluted, or just fugly. I would rather see us transfer this discussion list to an open forum hosted by 'netrexx.org' and let that site be the nexus of all things NetRexx. If Kenai is as robust and vibrant as you claim, it won't take more than a couple of discussion topic postings there to drive a lot of eyeballs to the netrexx.org site. Who knows, they may want to mirror the netrexx.org discussion. Or not. I know that if I were looking for something to do with NetRexx I'd start with that domain, not some aggregator with hundreds of other Java projects to wade through. More likely, we will start to see NetRexx topics showing up on other Java discussion sites, when the issue is more of a Java or platform matter than a NetRexx language matter. This is already the case with Classic Rexx topics on z/VM, z/OS, and z/VSE discussion lists. Like oorexx.org, netrexx.org could also provide a simpler interface to whatever SVN site is used, as well as hosting discussion groups, tutorials, application code libraries, etc. Most importantly, I do NOT want to put all the NetRexx eggs in any one basket that we don't have a firm grip on. And RexxLA remains the center of all things "Rexx", pointing to the ooRexx.org and netrexx.org sites, as authoritative resources for their members. -Chip- On 10/13/10 13:32 Thomas Schneider said: > Let me repeat the reason (*my reason*) *why* we should use www.KENAI.com > *and not* SourceForge for the open source release of Netrexx: > > 1.) SourceForge holds any kinds of projects. > 2.) www.KENAI.com holds *only Java related* projects. > 3.) When putting NetRexx to www.KENAI.com, we can easily *exploit* both > it's language recognition to a very broad user base.... > > Am 13.10.2010 15:05, schrieb René Jansen: >> for your information, ooRexx also has discussion groups that are open >> to everyone that registers, at SourceForge. >> >> On 13 okt 2010, at 14:54, Thomas Schneider wrote: >>> I think, however, that ooRexx and NetRexx discussions should be >>> splitted, >>> having an OWN NetRexx group, which I think should be OPEN. >>> >>> Also, putting the OPEN source of NetRexx on www.KENAI.com would give >>> NetRexx an instant *visibility* to the Java minded people. As far as >>> I can remember, some 50.000 very knowledgable individuals/companies >>> are a member of www.KENAI.com with various Java related projects. >>> >>> Far more, as any *own NetRexx* activity can build up quickly.... >>> >>> As far as I got the rules, www.KENAI.com has a very excelennt *standard* >>> Project scheme we could simply re-use, thus avoiding all the hassles >>> to build everything up again from scratch ... _______________________________________________ Ibm-netrexx mailing list [hidden email] |
RE: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
In reply to this post by Patric Bechtel-2
> > Umm, since you can emit Java code from the NetRexx, then throw away > > the NetRexx source -- you now have a purely Java project. > > Cannot get > > much more mixable than all the same language, surely? > > As I said: As long as you can get your dependencies worked > out, it's that way. But in the worst of cases, you cannot > generate Java code because NetRexx insists on having a Java > class compiled first, which itself might depend on NetRexx > generating a Java file first. And believe me, I'm not > constructing that. So having the stubs option would solve > these cases almost completely. Ah yes, if you have interdependencies between two source files which are in different languages, you're in trouble (I suspect that's true in any pair of languages). But in that case, I'm not sure that stubs will always be a solution, if the interdependencies appear in (say) the signatures of methods. So, does creating the stubs also imply "don't report any errors"? In that case another approach might be for NetRexxC to have an option that means "if you cannot find a method/class, assume it's an inderdependency and continue anyway". Of course that means that 'bad' code would be generated if (say) a programmer mistyped a method name, so it would have to be used with caution... Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] |
RE: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
In reply to this post by George Hovey-2
I'm embarrassed to admit that I've never looked at that
form of Java source let alone wondered why it existed (it sounded like pretty
printing) -- for obvious reasons I've focused on the version that corellates one
to one with the NetRexx source.
Yes, the "pretty
printed" version is quite workable. Not necessarily what the Java
programmer would write, but understandable. An example
below.
But I see now that it too is an important guarantor of
safety: no future NetRexx development can rob you of what you have already
produced, a strong promise indeed. Such "talking points" should feature
prominently in the NetRexx relaunch press release when it is written.
Indeed...
Mike
Segment of NetRexx code:
/* Create a copy
of set for working settings */
-- Note: no need to check for lostDigits again. -- 1999.07.17 Note: this construction must follow RHS check workset=MathContext(workdigits, set.form, 0, set.roundingMode)
res=ONE
-- accumulator
if n=0 then return res -- x**0 == 1 if n<0 then n=-n -- [rhs.ind records the sign] seenbit=boolean 0 -- set once we've seen a 1-bit loop i=1 by 1 -- for each bit [top bit ignored] n=n+n -- shift left 1 bit if n<0 then do -- top bit is set seenbit=1 -- OK, we're off res=res.multiply(lhs, workset) -- acc=acc*x end if i=31 then leave -- that was the last bit if \seenbit then iterate -- we don't have to square 1 res=res.multiply(res, workset) -- acc=acc*acc [square] end i -- 32 bits if rhs.ind<0 then -- was a **-n [hence digits>0] res=ONE.divide(res, workset) -- .. so acc=1/acc return res.finish(set, 1) -- round and strip [original digits] Generated Java:
/* Create a copy of set for
working settings */
// Note: no need to check for lostDigits again. // 1999.07.17 Note: this construction must follow RHS check workset=new com.ibm.math.MathContext(workdigits,set.form,false,set.roundingMode); res=ONE; //
accumulator
if (n==0) return res; // x**0 == 1 if (n<0) n=(int)-n; // [rhs.ind records the sign] seenbit=false; // set once we've seen a 1-bit {i=1;i:for(;;i++){ // for each bit [top bit ignored] n=n+n; // shift left 1 bit if (n<0) { // top bit is set seenbit=true; // OK, we're off res=res.multiply(lhs,workset); // acc=acc*x } if (i==31) break i; // that was the last bit if ((!seenbit)) continue i; // we don't have to square 1 res=res.multiply(res,workset); // acc=acc*acc [square] } }/*i*/ // 32 bits if (rhs.ind<0) // was a **-n [hence digits>0] res=ONE.divide(res,workset); // .. so acc=1/acc return res.finish(set,true); // round and strip [original digits] _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
In reply to this post by Mike Cowlishaw
Mike Cowlishaw schrieb am 14.10.2010 08:25:
>> As I said: As long as you can get your dependencies worked >> out, it's that way. But in the worst of cases, you cannot >> generate Java code because NetRexx insists on having a Java >> class compiled first, which itself might depend on NetRexx >> generating a Java file first. And believe me, I'm not >> constructing that. So having the stubs option would solve >> these cases almost completely. > > Ah yes, if you have interdependencies between two source files which are in > different languages, you're in trouble (I suspect that's true in any pair of > languages). > > But in that case, I'm not sure that stubs will always be a solution, if the > interdependencies appear in (say) the signatures of methods. So, does creating > the stubs also imply "don't report any errors"? In that case another approach > might be for NetRexxC to have an option that means "if you cannot find a > method/class, assume it's an inderdependency and continue anyway". > > Of course that means that 'bad' code would be generated if (say) a programmer > mistyped a method name, so it would have to be used with caution... Of course you're right with the 'ignore errors' option in combination with the stubs. But as the unified compiler of Groovy shows, the stubs are a very nice way to work around almost all interdependency problems so far - and I would love to have the opportunity to use NetRexx and Java (take Groovy into the mix, then...) without having to care for dependencies between them. A mistyped method name would be solved either by Javac or Netrexxc, which ever is affected, so I don't see a problem, even. Anyway, as soon as I can get my hands upon the source, I will implement that; might be the top priority for us. P.S.: Do you still remember us discussing about this in January 2005 already? My suggestion that time was to have -nocompile not balking on errors... very similar somehow. -- cu, Patric _______________________________________________ Ibm-netrexx mailing list [hidden email] |
RE: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
> Of course you're right with the 'ignore errors' option in > combination with the stubs. But as the unified compiler of > Groovy shows, the stubs are a very nice way to work around > almost all interdependency problems so far - and I would love > to have the opportunity to use NetRexx and Java (take Groovy > into the mix, then...) without having to care for > dependencies between them. OK. > A mistyped method name would be solved either by Javac or > Netrexxc, which ever is affected, so I don't see a problem, even. The main problem is that you'd get messages from javac -- which should never happen with NetRexx. However in the 'mixed' situation you're talking about, that might not be so bad. A purpose-made stub option 'not recommended for use by the starter NetRexx programmer' is probably best. > Anyway, as soon as I can get my hands upon the source, I will > implement that; might be the top priority for us. OK. > P.S.: Do you still remember us discussing about this in > January 2005 already? My suggestion that time was to have > -nocompile not balking on errors... very similar somehow. No I don't recall, although no doubt I have the e-mails... Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)
|
|
In reply to this post by Patric Bechtel-2
May I underline the -stubs option as one of the most important on my
personal priority list :-) Thomas. ======================================================== Am 13.10.2010 21:10, schrieb Patric Bechtel: > Hi Mike, > > Mike Cowlishaw schrieb am 13.10.2010 20:48: >> No reason why not to add that to NetRexx :-). In fact probably >> almost trivial >> to effect -- just a 'skip phase 3' option in the compiler and a test >> or two in >> the main generator loop. > > Sounds too good to be true. I'm looking forward playing with the > source to get that working ASAP. Would be a real time saver, really. > >>> Bottom line is: be careful to tell you can mix NetRexx and >>> Java. It's interoperable, but not mixable. >> >> Umm, since you can emit Java code from the NetRexx, then throw away >> the NetRexx >> source -- you now have a purely Java project. Cannot get much more >> mixable than >> all the same language, surely? > > As I said: As long as you can get your dependencies worked out, it's > that way. But in the worst of cases, you cannot generate Java code > because NetRexx insists on having a Java class compiled first, which > itself might depend on NetRexx generating a Java file first. And > believe me, I'm not constructing that. So having the stubs option > would solve these cases almost completely. > -- Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |