ibm-netrexx

Eclipse compiler and NetRexx build

Classic

List

Threaded

56 messages Options

123

Kermit Kiser

Eclipse compiler and NetRexx build

René --

I have merged the changes to support the Eclipse compiler into the
"after3.01" experimental NetRexx branch and tested them successfully.
However, I discovered that there is no way to pass the "nrx.compiler"
Java system property from an Ant build to NetRexx. After modifying our
NetRexx source for the ant-netrexx.jar task to set the Java property
from an Ant property value, I was able to run the entire NetRexx build
using the Eclipse Java compiler (ecj). The Ant property can be set using
either a property name matching the existing ant.netrexx properties or
using the same name as the Java property NetRexx looks for:

<property name="ant.netrexxc.javacompiler" value="ecj"/>
or
<property name="nrx.compiler" value="ecj"/>

Although this approach works OK, it has the drawback that Ant properties
cannot be modified once set which means that all subsequent NetRexx
compiles will use the same value. That may not be flexible enough for
all cases. Also the NetRexx compiler API has no provision for selecting
the compiler. For these reasons, I suggest that we consider a new
compiler option to specify the Java compiler.

One more thing I discovered about this option: Since the distributed
NetRexxC compile scripts pass the environment variable "netrexx_java" to
the Java VM at start, if there is no need for alternate NetRexx compiles
on a system, the compiler selection can be placed in the environment and
no change to the NetRexxC script is required. In Windows for example:

set netrexx_java=-Dnrx.compile=ecj

I will commit these changes soon.

-- Kermit

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

rvjansen

Re: Eclipse compiler and NetRexx build

Hi Kermit,

thanks for looking into this, and for the rediscovery of the
netrexx_java variable. I have used it once, years ago and have
subsequently forgotten all about it, skipping NetRexxC.sh most of the
time. I will add this to the Quick Start Guide; I am surprised ant does
not give easy access to java environment options - but thanks for fixing
that.

We can have a new option, so we cater for all the ways that we can
specify the backend compiler. My impression, however, is that the
'options' mechanism crosses the boundaries between the language and the
runtime, and that choice of a backend compiler is something better left
out of the program source, for portability reasons. But I am not opposed
to it; we do need to put it on the agenda for the ARB however.

On a side note, I think we do need to review all of the options
statements somewhere soon; there are/have been some slight problems with
precedence, and I am not unsympathetic to some of the claims that the
consequences of flipping options binary can be explained with more
clarity, or need additional treatment to keep the meaning of the source
program stable. Also, with options utf8 turning out to be non-optional
on the command line when specified in the program source, we could look
into getting rid of it entirely (by having it enabled as standard, maybe
allowing more unicode encodings in a standard way - I do not know the
drawbacks - a standard grammar would do some slower scanning with larger
characters set space so I can imagine NetRexx also does).

Looking forward to your commits,

best regards,

René.

On 2012-09-01 04:42, Kermit Kiser wrote:

> René --
>
> I have merged the changes to support the Eclipse compiler into the
> "after3.01" experimental NetRexx branch and tested them successfully.
> However, I discovered that there is no way to pass the "nrx.compiler"
> Java system property from an Ant build to NetRexx. After modifying
> our
> NetRexx source for the ant-netrexx.jar task to set the Java property
> from an Ant property value, I was able to run the entire NetRexx
> build
> using the Eclipse Java compiler (ecj). The Ant property can be set
> using either a property name matching the existing ant.netrexx
> properties or using the same name as the Java property NetRexx looks
> for:
>
> <property name="ant.netrexxc.javacompiler" value="ecj"/>
> or
> <property name="nrx.compiler" value="ecj"/>
>
> Although this approach works OK, it has the drawback that Ant
> properties cannot be modified once set which means that all
> subsequent
> NetRexx compiles will use the same value. That may not be flexible
> enough for all cases. Also the NetRexx compiler API has no provision
> for selecting the compiler. For these reasons, I suggest that we
> consider a new compiler option to specify the Java compiler.
>
> One more thing I discovered about this option: Since the distributed
> NetRexxC compile scripts pass the environment variable "netrexx_java"
> to the Java VM at start, if there is no need for alternate NetRexx
> compiles on a system, the compiler selection can be placed in the
> environment and no change to the NetRexxC script is required. In
> Windows for example:
>
> set netrexx_java=-Dnrx.compile=ecj
>
> I will commit these changes soon.
>
> -- Kermit
>
>
>
> _______________________________________________
> 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/

billfen

Re: Eclipse compiler and NetRexx build

I'm not quite sure I understand the advantages of using the Eclipse
compiler without using Eclipse?

In a normal Eclipse Java project, there is a menu selection which will
trigger a build. Additionally and more importantly, there is a project
option to build automatically. In that case any change to a java file
triggers a project build and the compiles are done as needed.

When using the Eclipse NetRexx plugin, compiling a nrx file generates a
new Java file (in the src directory tree), and that file is
automatically compiled with the Eclipse Java compiler (into the bin
directory tree). In a project with multiple nrx files, the normal
process is to change a nrx file, save it and hit F11 to debug the
project using the Eclipse Java debugger, hit C-F11 to run it directly,
or perhaps export the project into a jar file using a menu option.

The Eclipse setup description for the NetRexx source repository that I
provided assumes that the normal mode of operation would be to make nrx
file changes as necessary, then to directly select the batch Ant build.

I think there would be some advantages in organizing the repository
files as an Eclipse project, but I assume there is not much interest in
(and perhaps some resistance to) doing that. I'm currently looking into
doing it for myself, but I'm concentrating on finishing the next version
of the Eclipse plugin first.

I believe that if the NetRexx source repository were set up as Eclipse
project(s) that it would not hinder any development approach not using
Eclipse, but it might require minor changes. I believe that Eclipse and
NetBeans projects can be generally compatible.

The differences would probably be to include both the nrx and java files
in the src directory structure and the use of the bin directory for the
class files rather than the build directory structure. There may be
more involved, but I haven't tried it yet. There may be ways of using
the existing repository structure and a custom build. The existing Ant
build could be used as is or could be changed to use the class files in
the bin directory.

Bill

On 9/3/2012 2:31 AM, rvjansen wrote:

> Hi Kermit,
>
> thanks for looking into this, and for the rediscovery of the
> netrexx_java variable. I have used it once, years ago and have
> subsequently forgotten all about it, skipping NetRexxC.sh most of the
> time. I will add this to the Quick Start Guide; I am surprised ant
> does not give easy access to java environment options - but thanks for
> fixing that.
>
> We can have a new option, so we cater for all the ways that we can
> specify the backend compiler. My impression, however, is that the
> 'options' mechanism crosses the boundaries between the language and
> the runtime, and that choice of a backend compiler is something better
> left out of the program source, for portability reasons. But I am not
> opposed to it; we do need to put it on the agenda for the ARB however.
>
> On a side note, I think we do need to review all of the options
> statements somewhere soon; there are/have been some slight problems
> with precedence, and I am not unsympathetic to some of the claims that
> the consequences of flipping options binary can be explained with more
> clarity, or need additional treatment to keep the meaning of the
> source program stable. Also, with options utf8 turning out to be
> non-optional on the command line when specified in the program source,
> we could look into getting rid of it entirely (by having it enabled as
> standard, maybe allowing more unicode encodings in a standard way - I
> do not know the drawbacks - a standard grammar would do some slower
> scanning with larger characters set space so I can imagine NetRexx
> also does).
>
> Looking forward to your commits,
>
> best regards,
>
> René.
>
> On 2012-09-01 04:42, Kermit Kiser wrote:
>> René --
>>
>> I have merged the changes to support the Eclipse compiler into the
>> "after3.01" experimental NetRexx branch and tested them successfully.
>> However, I discovered that there is no way to pass the "nrx.compiler"
>> Java system property from an Ant build to NetRexx. After modifying our
>> NetRexx source for the ant-netrexx.jar task to set the Java property
>> from an Ant property value, I was able to run the entire NetRexx build
>> using the Eclipse Java compiler (ecj). The Ant property can be set
>> using either a property name matching the existing ant.netrexx
>> properties or using the same name as the Java property NetRexx looks
>> for:
>>
>> <property name="ant.netrexxc.javacompiler" value="ecj"/>
>> or
>> <property name="nrx.compiler" value="ecj"/>
>>
>> Although this approach works OK, it has the drawback that Ant
>> properties cannot be modified once set which means that all subsequent
>> NetRexx compiles will use the same value. That may not be flexible
>> enough for all cases. Also the NetRexx compiler API has no provision
>> for selecting the compiler. For these reasons, I suggest that we
>> consider a new compiler option to specify the Java compiler.
>>
>> One more thing I discovered about this option: Since the distributed
>> NetRexxC compile scripts pass the environment variable "netrexx_java"
>> to the Java VM at start, if there is no need for alternate NetRexx
>> compiles on a system, the compiler selection can be placed in the
>> environment and no change to the NetRexxC script is required. In
>> Windows for example:
>>
>> set netrexx_java=-Dnrx.compile=ecj
>>
>> I will commit these changes soon.
>>
>> -- Kermit

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

ThSITC

Re: Eclipse compiler and NetRexx build

In reply to this post by rvjansen

Hi Rene, Kermit, and all ...

I am currently vry busy to release my stuff ...

... but:

I also did start, in a new subdirectory, *not* in
org.netrexx.thsitc.runtime.compatibiliy,

*******************************************************
* to *split* *NetRexx Class Rexx*
*******************************************************

to the following new classes:

Text -- simply a Text. Might be, however, a Rexx String *or* a
Java String!
Reason for this is to enable usage of any Java
String methods on Text's, as well as Rexx methods. ;-)

Numeric -- simply any kind of Numerics, using either anciet NetRexx
class Rexx algorithms, *or* MFC's BigDecimal class,
*or* Java's BigDecimal class.

Logical -- *also called+ Boolean, in some languages, as NetRexx, but
with TRUE and FALSE +predefined-

Trinary -- brand new *Trinary Logic* (true, false, *not yet known*
(for short: *unknown*))

Stem -- as in classic Rexx/ooRexx/Regina, calld *Indexed String*
in NetRexx, however.

==========================================================================

Rexx then is, for upwards compatibility, something like a *SuperClass*
(in ooRexx Terminology)

Still *experimental* fot my *personal usage*, *and* tests, however.

************************************************************************************
* Just for your info (*no advertisements* *nor* release dates yet
defined ...
************************************************************************************

Thomas.
============================================================================
Am 03.09.2012 08:31, schrieb rvjansen:

--
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

ThSITC

Re: Eclipse compiler and NetRexx build

Oh, as always: Typing to quick ... (before code review ...)

there is also a *new class* Number.

*and*

I am proposing to new keywords: *Positive* ***and*** *Negative*

thus. you might write:

a=Positive Number
b=Negative Number

This looks very *human* for me, and would allow the NetRexx 4.00
compiler/Interpreter
to *check this*, at runtime.... !!!!!!!!!

Same should apply for Numeric's, of course, but *not* for Tex's and
Logicals ... ;-)

A Positive Boolean dos *not exist* <grin>
Detto: A Negative Text <grin>

========================================================
End of suggestions for NetRexx 4.00, by the way, from my side, at least
========================================================

*I* do call this (new) Language *Rey*, for brevity ... <grin>

Thomas.
===========================================================

Am 03.09.2012 23:36, schrieb Thomas Schneider:

> Hi Rene, Kermit, and all ...
>
> I am currently vry busy to release my stuff ...
>
> ... but:
>
> I also did start, in a new subdirectory, *not* in
> org.netrexx.thsitc.runtime.compatibiliy,
>
> *******************************************************
> * to *split* *NetRexx Class Rexx*
> *******************************************************
>
> to the following new classes:
>
> Text -- simply a Text. Might be, however, a Rexx String *or*
> a Java String!
> Reason for this is to enable usage of any Java
> String methods on Text's, as well as Rexx methods. ;-)
>
> Numeric -- simply any kind of Numerics, using either anciet NetRexx
> class Rexx algorithms, *or* MFC's BigDecimal class,
> *or* Java's BigDecimal class.
>
> Logical -- *also called+ Boolean, in some languages, as NetRexx,
> but with TRUE and FALSE +predefined-
>
> Trinary -- brand new *Trinary Logic* (true, false, *not yet known*
> (for short: *unknown*))
>
> Stem -- as in classic Rexx/ooRexx/Regina, calld *Indexed String*
> in NetRexx, however.
>
> ==========================================================================
>
>
> Rexx then is, for upwards compatibility, something like a *SuperClass*
> (in ooRexx Terminology)
>
> Still *experimental* fot my *personal usage*, *and* tests, however.
>
> ************************************************************************************
>
> * Just for your info (*no advertisements* *nor* release dates yet
> defined ...
> ************************************************************************************
>
>
> Thomas.
> ============================================================================
>
> Am 03.09.2012 08:31, schrieb rvjansen:
>> Hi Kermit,
>>
>> thanks for looking into this, and for the rediscovery of the
>> netrexx_java variable. I have used it once, years ago and have
>> subsequently forgotten all about it, skipping NetRexxC.sh most of the
>> time. I will add this to the Quick Start Guide; I am surprised ant
>> does not give easy access to java environment options - but thanks
>> for fixing that.
>>
>> We can have a new option, so we cater for all the ways that we can
>> specify the backend compiler. My impression, however, is that the
>> 'options' mechanism crosses the boundaries between the language and
>> the runtime, and that choice of a backend compiler is something
>> better left out of the program source, for portability reasons. But I
>> am not opposed to it; we do need to put it on the agenda for the ARB
>> however.
>>
>> On a side note, I think we do need to review all of the options
>> statements somewhere soon; there are/have been some slight problems
>> with precedence, and I am not unsympathetic to some of the claims
>> that the consequences of flipping options binary can be explained
>> with more clarity, or need additional treatment to keep the meaning
>> of the source program stable. Also, with options utf8 turning out to
>> be non-optional on the command line when specified in the program
>> source, we could look into getting rid of it entirely (by having it
>> enabled as standard, maybe allowing more unicode encodings in a
>> standard way - I do not know the drawbacks - a standard grammar would
>> do some slower scanning with larger characters set space so I can
>> imagine NetRexx also does).
>>
>> Looking forward to your commits,
>>
>> best regards,
>>
>> René.
>>
>> On 2012-09-01 04:42, Kermit Kiser wrote:
>>> René --
>>>
>>> I have merged the changes to support the Eclipse compiler into the
>>> "after3.01" experimental NetRexx branch and tested them successfully.
>>> However, I discovered that there is no way to pass the "nrx.compiler"
>>> Java system property from an Ant build to NetRexx. After modifying our
>>> NetRexx source for the ant-netrexx.jar task to set the Java property
>>> from an Ant property value, I was able to run the entire NetRexx build
>>> using the Eclipse Java compiler (ecj). The Ant property can be set
>>> using either a property name matching the existing ant.netrexx
>>> properties or using the same name as the Java property NetRexx looks
>>> for:
>>>
>>> <property name="ant.netrexxc.javacompiler" value="ecj"/>
>>> or
>>> <property name="nrx.compiler" value="ecj"/>
>>>
>>> Although this approach works OK, it has the drawback that Ant
>>> properties cannot be modified once set which means that all subsequent
>>> NetRexx compiles will use the same value. That may not be flexible
>>> enough for all cases. Also the NetRexx compiler API has no provision
>>> for selecting the compiler. For these reasons, I suggest that we
>>> consider a new compiler option to specify the Java compiler.
>>>
>>> One more thing I discovered about this option: Since the distributed
>>> NetRexxC compile scripts pass the environment variable "netrexx_java"
>>> to the Java VM at start, if there is no need for alternate NetRexx
>>> compiles on a system, the compiler selection can be placed in the
>>> environment and no change to the NetRexxC script is required. In
>>> Windows for example:
>>>
>>> set netrexx_java=-Dnrx.compile=ecj
>>>
>>> I will commit these changes soon.
>>>
>>> -- Kermit
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/
>>
>
>

Thomas Schneider, Vienna, Austria (Europe) :-)

www.thsitc.com
www.db-123.com

Marc Remes-2

Re: Eclipse compiler and NetRexx build

In reply to this post by billfen

On 09/03/2012 01:21 PM, Bill Fenlason wrote:
> The differences would probably be to include both the nrx and java files in the src directory structure and the use of
> the bin directory for the class files rather than the build directory structure.

I am a bit opposed to have real source files and generated ones in the same directory.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

billfen

Re: Eclipse compiler and NetRexx build

Marc, I agree - using the same folder for both nrx and java files is not
a good idea. I said that because that might be the easiest approach.

Usually Java is in a \src directory, and I'm not sure if the NetRexx
files should be in \src or in a different directory like \nrx or
whatever. No doubt there can be a way to have the directory names as
user specified, and can be either different or the same in any combination.

The current Ant build uses the \src directory for the nrx files, and the
\build\classes directory for both the java and class files and copies of
the nrx files.

I think using \src for the nrx files, \bin for the class files and
something like \java for the java files might be reasonable, but as I
said, I haven't gotten into it yet. Ideally each of the three directory
names could be user specified. (I did that with my netrexx3 Ant task.
I'm not sure if the new Ant task - written in NetRexx - does it that
way. Rene? Kermit?)

What is the most common approach used? Do most users just use \src for
the nrx files and let the Ant build do the rest?

From an Eclipse standpoint, I think having the java and class files in
the same directory is not a good idea - the Eclipse convention is \src
and \bin but I think they can be user specified.

On 9/4/2012 4:36 AM, Marc Remes wrote:
> On 09/03/2012 01:21 PM, Bill Fenlason wrote:
>> The differences would probably be to include both the nrx and java
>> files in the src directory structure and the use of
>> the bin directory for the class files rather than the build directory
>> structure.
>
> I am a bit opposed to have real source files and generated ones in the
> same directory.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

rvjansen

Re: Eclipse compiler and NetRexx build

In reply to this post by Marc Remes-2

Marc,

I understand. It is not the intention of anyone in the development team
to impose a way of working on anyone else. We strive for a peaceful
coexistence of different editors and tools. Personally, I do not mind
java-and-class-in-source, but we have adapted to the current standard
here. If we are trying to comply to other tools and standards, they will
be additions, and we will try to never take anything away. People who
are users of specific development environments will be supported as well
as possible, but are most of the time very well able to do their own
adaptations, using NetRexx where possible of course.

So the most important thing is not to rule out anything that people
might do on their own systems by imposing a fixed structure in svn - I
think we have succeeded in that. Only peculiarities of the NetRexx
implementation can ever lead to imposing

best regards,

René.

On 2012-09-04 10:36, Marc Remes wrote:

> On 09/03/2012 01:21 PM, Bill Fenlason wrote:
>> The differences would probably be to include both the nrx and java
>> files in the src directory structure and the use of
>> the bin directory for the class files rather than the build
>> directory structure.
>
> I am a bit opposed to have real source files and generated ones in
> the same directory.
>
>
> _______________________________________________
> 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/

billfen

Re: Eclipse compiler and NetRexx build

Rene,

It appears that the current repository structure already includes
development environment specific files. For example, the netrexxc
directory currently includes numerous .bat, .cmd, makefile, and .sh
files (and even a .rex file), as well as an emacs-mode and other files.

With that precedent in mind, will you support the inclusion of .project
or other files which are used by IDS's such as NetBeans and Eclipse in
the netrexxc directory?

Bill

On 9/4/2012 6:24 AM, rvjansen wrote:

> Marc,
>
> I understand. It is not the intention of anyone in the development
> team to impose a way of working on anyone else. We strive for a
> peaceful coexistence of different editors and tools. Personally, I do
> not mind java-and-class-in-source, but we have adapted to the current
> standard here. If we are trying to comply to other tools and
> standards, they will be additions, and we will try to never take
> anything away. People who are users of specific development
> environments will be supported as well as possible, but are most of
> the time very well able to do their own adaptations, using NetRexx
> where possible of course.
>
> So the most important thing is not to rule out anything that people
> might do on their own systems by imposing a fixed structure in svn - I
> think we have succeeded in that. Only peculiarities of the NetRexx
> implementation can ever lead to imposing
>
> best regards,
>
> René.
>
>
>
> On 2012-09-04 10:36, Marc Remes wrote:
>> On 09/03/2012 01:21 PM, Bill Fenlason wrote:
>>> The differences would probably be to include both the nrx and java
>>> files in the src directory structure and the use of
>>> the bin directory for the class files rather than the build
>>> directory structure.
>>
>> I am a bit opposed to have real source files and generated ones in
>> the same directory.
>>
>>
>> _______________________________________________
>> 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/
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2197 / Virus Database: 2437/5246 - Release Date: 09/03/12

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Marc Remes-2

Re: Eclipse compiler and NetRexx build

In reply to this post by rvjansen

Don't get me wrong René, I'm for peaceful coexistence as well ;

On my Indigo eclipse installation, the default directories for a Java project are /src for java files and /bin for class
files. Both are configurable.
I think it is best to keep those as is and use the /src directory also for netrexx source files. The netrexx source
files would compile to a /generated-java directory from where the class files would be built to the /bin directory.

That way we can combine both java files and netrexx in the same project. And it's most compatible with existing.

--

Marc

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

billfen

Re: Eclipse compiler and NetRexx build

Given time and effort, an Eclipse wizard for NetRexx projects could
solve the problems by allowing any combination of nrx, java and class
files and directories, with the default being nrx and java in the \src
directory and classes in the \bin directory.

One long range goal is to integrate NetRexx into the Eclipse debugger.
I think that being able to specify breakpoints directly in NetRexx
source could be quite useful, as well as being able to use the many
other features of the Eclipse debugger. Trace and Print statements will
always have their place, but a sophisticated debugger can sometimes save
a lot of time.

And I still don't understand what the advantage of using the Eclipse
compiler without the Eclipse IDE is.

On 9/4/2012 7:11 AM, Marc Remes wrote:

> Don't get me wrong René, I'm for peaceful coexistence as well ;
>
> On my Indigo eclipse installation, the default directories for a Java
> project are /src for java files and /bin for class files. Both are
> configurable.
> I think it is best to keep those as is and use the /src directory also
> for netrexx source files. The netrexx source files would compile to a
> /generated-java directory from where the class files would be built to
> the /bin directory.
>
> That way we can combine both java files and netrexx in the same
> project. And it's most compatible with existing.
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

rvjansen

Re: Eclipse compiler and NetRexx build

Bill,

I saw your question, but time was lacking earlier to properly answer
it,

The intent is to enable compilation on JRE-only systems. It could have
been any other compiler, but the one from Eclipse is the best I found,
and combined with the licensing options it was the one that was chosen
for inclusion in the package.

This choice should not be construed as to be that this advantage is
that you can use the Eclipse compiler without having to use the IDE. On
the contrary, the systems that are in the target set for this solution,
with only a JRE available, would be greatly overlapping the set where it
would be impossible to install an Eclipse IDE - restrictions on running
an X server to see the IDE, rules for debuggers being available;
firewalls that open only certain ports; etc.

For simple statistics, I have access to about 6 or 7 machines and about
10 VM's in which I could install full Eclipse and/or Java SDK. Most of
these are in my home. There are at the moment around 6500 servers
professionally available to me which have only a JRE (but all the same
patch level and centrally managed) and no X - so no swing or awt or gwt.
Or on z/OS or z/VM, you might not be the sysprog allowed to install the
Java SDK.

An added advantage, and an investment into the future, is that we can
now support people who have an SDK and full admin access to their box,
but whose NetRexx installation cannot find the (deprecated) compiler
class archive. We can now point them or (the investment is towards) the
installer to a working, bytecodes and class files producing compiler.

So, there is no advantage to use the Eclipse Java Compiler without the
IDE in itself. But, I hope that you see that there is a clear advantage
in being able to compile NetRexx code when you cannot install Eclipse or
the SDK, or cannot find the SDK component you need.

best regards,

René.

On 2012-09-04 13:42, Bill Fenlason wrote:

> Given time and effort, an Eclipse wizard for NetRexx projects could
> solve the problems by allowing any combination of nrx, java and class
> files and directories, with the default being nrx and java in the
> \src
> directory and classes in the \bin directory.
>
> One long range goal is to integrate NetRexx into the Eclipse
> debugger. I think that being able to specify breakpoints directly in
> NetRexx source could be quite useful, as well as being able to use
> the
> many other features of the Eclipse debugger. Trace and Print
> statements will always have their place, but a sophisticated debugger
> can sometimes save a lot of time.
>
> And I still don't understand what the advantage of using the Eclipse
> compiler without the Eclipse IDE is.
>
>
> On 9/4/2012 7:11 AM, Marc Remes wrote:
>> Don't get me wrong René, I'm for peaceful coexistence as well ;
>>
>> On my Indigo eclipse installation, the default directories for a
>> Java project are /src for java files and /bin for class files. Both
>> are configurable.
>> I think it is best to keep those as is and use the /src directory
>> also for netrexx source files. The netrexx source files would compile
>> to a /generated-java directory from where the class files would be
>> built to the /bin directory.
>>
>> That way we can combine both java files and netrexx in the same
>> project. And it's most compatible with existing.
>>
>
> _______________________________________________
> 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/

billfen

Re: Eclipse compiler and NetRexx build

Thanks for the clear explanation. Isn't it possible to bundle the JDK
compiler as well as the Eclipse version? I suspect the JDK is much more
than javac.

As for Eclipse installation - I sometimes run it on my NetBook - an Asus
Eee - a bit old and slow but quite workable, even for development with
JDK and all. Surely you can install Eclipse on your Mac or Macbook? I
see that you can even install it on an iPad, and no doubt on other
tablets as well.

I suspect that if one can't install the pre-recs for NetRexx, then one
can't install NetRexx either. The last I knew, the elephant in the room
is still Windows and not X, unless of course you want to install the
compiler on a phone.

If you are into Android programming, perhaps you have noticed that the
ADK is somewhat slanted toward Eclipse.

On 9/4/2012 9:29 AM, rvjansen wrote:

> Bill,
>
> I saw your question, but time was lacking earlier to properly answer it,
>
> The intent is to enable compilation on JRE-only systems. It could have
> been any other compiler, but the one from Eclipse is the best I found,
> and combined with the licensing options it was the one that was chosen
> for inclusion in the package.
>
> This choice should not be construed as to be that this advantage is
> that you can use the Eclipse compiler without having to use the IDE.
> On the contrary, the systems that are in the target set for this
> solution, with only a JRE available, would be greatly overlapping the
> set where it would be impossible to install an Eclipse IDE -
> restrictions on running an X server to see the IDE, rules for
> debuggers being available; firewalls that open only certain ports; etc.
>
> For simple statistics, I have access to about 6 or 7 machines and
> about 10 VM's in which I could install full Eclipse and/or Java SDK.
> Most of these are in my home. There are at the moment around 6500
> servers professionally available to me which have only a JRE (but all
> the same patch level and centrally managed) and no X - so no swing or
> awt or gwt. Or on z/OS or z/VM, you might not be the sysprog allowed
> to install the Java SDK.
>
> An added advantage, and an investment into the future, is that we can
> now support people who have an SDK and full admin access to their box,
> but whose NetRexx installation cannot find the (deprecated) compiler
> class archive. We can now point them or (the investment is towards)
> the installer to a working, bytecodes and class files producing compiler.
>
> So, there is no advantage to use the Eclipse Java Compiler without the
> IDE in itself. But, I hope that you see that there is a clear
> advantage in being able to compile NetRexx code when you cannot
> install Eclipse or the SDK, or cannot find the SDK component you need.
>
> best regards,
>
> René.
>
>
> On 2012-09-04 13:42, Bill Fenlason wrote:
>> Given time and effort, an Eclipse wizard for NetRexx projects could
>> solve the problems by allowing any combination of nrx, java and class
>> files and directories, with the default being nrx and java in the \src
>> directory and classes in the \bin directory.
>>
>> One long range goal is to integrate NetRexx into the Eclipse
>> debugger. I think that being able to specify breakpoints directly in
>> NetRexx source could be quite useful, as well as being able to use the
>> many other features of the Eclipse debugger. Trace and Print
>> statements will always have their place, but a sophisticated debugger
>> can sometimes save a lot of time.
>>
>> And I still don't understand what the advantage of using the Eclipse
>> compiler without the Eclipse IDE is.
>>
>>
>> On 9/4/2012 7:11 AM, Marc Remes wrote:
>>> Don't get me wrong René, I'm for peaceful coexistence as well ;
>>>
>>> On my Indigo eclipse installation, the default directories for a
>>> Java project are /src for java files and /bin for class files. Both
>>> are configurable.
>>> I think it is best to keep those as is and use the /src directory
>>> also for netrexx source files. The netrexx source files would
>>> compile to a /generated-java directory from where the class files
>>> would be built to the /bin directory.
>>>
>>> That way we can combine both java files and netrexx in the same
>>> project. And it's most compatible with existing.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

rvjansen

Re: Eclipse compiler and NetRexx build

Hi Bill,

I am afraid you are still speaking about home machines here; these are not the problem, as long as you can find the compiler and sometimes some other classes; ' in the wild' there are a lot of machines that have a JRE and no JDK. This is driven by the need to execute Java programs; the JRE is sufficient for that and for that reason a JRE and no JDK is installed. You are correct that the SDK is a better solution, in the sense that it installs a number of tools that you might want to use while developing - none of which is required for compiling a NetRexx program, which is our core business.

The first reason we cannot do this is the Oracle license agreement. We might bundle OpenJDK stuff but that is out of scope for the moment, for the other reason. The other reason is size.

Not being able to install Eclipse sometimes has nothing to do with the capacity - some of my customers have thousands of shiny new I7's with 4GB that are exceptionally well locked down. I personally have Eclipse on all my macs, in mountable partitions because of the poor product planning for running several versions. One of them is even dedicated to testing your Eclipse plugin (and on my macs several Linux VM's with Eclipse versions for WAS maintenance, Rational dev environments, MQ Explorer, et cetera).

Your suspicion about the consequences of not being able to install the prereqs for NetRexx for the installation of NetRexx itself is incorrect. NetRexx is a jar, and a binary upload to a part of a file system of a JVM equiped computer that you have write authorization to suffices to enable compilation of source code - now that we have ecj bundled. "Installation" in the sense of adding software packages to a system entails sometimes adding to registries or component/shared libraries/dll asset repositories, all of which are controlled in modern environments. Funny that you mention Windows, where the space in the pathnames probably causes 90% of all 'javac not found' errors. And the problems you have with installing software on a phone are the same as the ones you encounter on a mainframe: try to use Java GUI without a working X client or VNC server, and try to use distributed Eclipse when you do not control the company firewall.

And I did notice the proclivity toward Eclipse for Android; but unless I can have a command line toolchain I am not going to do it; I make my own choices on where to waste my time and unless it is paid for I am not going to spend it on ever-changing dialog boxes and debugging configurations of changing versions of it.

I respect and encourage you to enable Eclipse debugging for NetRexx. Last time I have used that is in 2003 on NetBeans and I remember the source line fixups for NetRexx in the generated class work very well; it is just not for me, because the debuggers are so slow - what I can find (the type of errors that I am prone to commit) in 5 seconds using trace I can't do in 5 minutes in a GUI debugger; I am of the type that scripts gdb because of aversion of repetitive movements. And debugging server based code in a GUI enters a whole different dimension - starting with finding the right JVM options for remote debugging (oops. the remote JVM is a different brand/release/patch then your local JVM - oops the firewall does block the rmi ports) - I am so grateful for trace that I probably can be blackmailed by people threatening to take it out.

So enabling the compiling of NetRexx on JRE only machine, non-graphical environments does not have any consequence for the acceptance of Eclipse on admin-equiped Windows machines with working Java GUI's - it is enabling those other environments. And the Windows environments that don't work. I think the best strategy to promote Eclipse is to make a working, one size fits all plugin that people can download and use right away. When it is kept up to date with the NetRexx releases (and Eclipse releases), it might truly the best solution for this segment of the market. We do miss the manpower to do that currently, and I hope you are on board to assist with that.

best regards,

René.

On 4 sep. 2012, at 16:08, Bill Fenlason <[hidden email]> wrote:

> Thanks for the clear explanation. Isn't it possible to bundle the JDK compiler as well as the Eclipse version? I suspect the JDK is much more than javac.
>
> As for Eclipse installation - I sometimes run it on my NetBook - an Asus Eee - a bit old and slow but quite workable, even for development with JDK and all. Surely you can install Eclipse on your Mac or Macbook? I see that you can even install it on an iPad, and no doubt on other tablets as well.
>
> I suspect that if one can't install the pre-recs for NetRexx, then one can't install NetRexx either. The last I knew, the elephant in the room is still Windows and not X, unless of course you want to install the compiler on a phone.
>
> If you are into Android programming, perhaps you have noticed that the ADK is somewhat slanted toward Eclipse.
>
> On 9/4/2012 9:29 AM, rvjansen wrote:
>> Bill,
>>
>> I saw your question, but time was lacking earlier to properly answer it,
>>
>> The intent is to enable compilation on JRE-only systems. It could have been any other compiler, but the one from Eclipse is the best I found, and combined with the licensing options it was the one that was chosen for inclusion in the package.
>>
>> This choice should not be construed as to be that this advantage is that you can use the Eclipse compiler without having to use the IDE. On the contrary, the systems that are in the target set for this solution, with only a JRE available, would be greatly overlapping the set where it would be impossible to install an Eclipse IDE - restrictions on running an X server to see the IDE, rules for debuggers being available; firewalls that open only certain ports; etc.
>>
>> For simple statistics, I have access to about 6 or 7 machines and about 10 VM's in which I could install full Eclipse and/or Java SDK. Most of these are in my home. There are at the moment around 6500 servers professionally available to me which have only a JRE (but all the same patch level and centrally managed) and no X - so no swing or awt or gwt. Or on z/OS or z/VM, you might not be the sysprog allowed to install the Java SDK.
>>
>> An added advantage, and an investment into the future, is that we can now support people who have an SDK and full admin access to their box, but whose NetRexx installation cannot find the (deprecated) compiler class archive. We can now point them or (the investment is towards) the installer to a working, bytecodes and class files producing compiler.
>>
>> So, there is no advantage to use the Eclipse Java Compiler without the IDE in itself. But, I hope that you see that there is a clear advantage in being able to compile NetRexx code when you cannot install Eclipse or the SDK, or cannot find the SDK component you need.
>>
>> best regards,
>>
>> René.
>>
>>
>> On 2012-09-04 13:42, Bill Fenlason wrote:
>>> Given time and effort, an Eclipse wizard for NetRexx projects could
>>> solve the problems by allowing any combination of nrx, java and class
>>> files and directories, with the default being nrx and java in the \src
>>> directory and classes in the \bin directory.
>>>
>>> One long range goal is to integrate NetRexx into the Eclipse
>>> debugger. I think that being able to specify breakpoints directly in
>>> NetRexx source could be quite useful, as well as being able to use the
>>> many other features of the Eclipse debugger. Trace and Print
>>> statements will always have their place, but a sophisticated debugger
>>> can sometimes save a lot of time.
>>>
>>> And I still don't understand what the advantage of using the Eclipse
>>> compiler without the Eclipse IDE is.
>>>
>>>
>>> On 9/4/2012 7:11 AM, Marc Remes wrote:
>>>> Don't get me wrong René, I'm for peaceful coexistence as well ;
>>>>
>>>> On my Indigo eclipse installation, the default directories for a Java project are /src for java files and /bin for class files. Both are configurable.
>>>> I think it is best to keep those as is and use the /src directory also for netrexx source files. The netrexx source files would compile to a /generated-java directory from where the class files would be built to the /bin directory.
>>>>
>>>> That way we can combine both java files and netrexx in the same project. And it's most compatible with existing.
>
> _______________________________________________
> 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/

Jason Martin

Re: Eclipse compiler and NetRexx build

In reply to this post by Kermit Kiser

The real reason I made the suggestion in the original post about the ecj compiler was to put NetRexx on a level platform with other scripting languages or give it something they did not have. One of the real advantages to NetRexx is so much POWER in such a SMALL package.

You just do not find that today.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

ThSITC

Re: Eclipse compiler and NetRexx build

In reply to this post by billfen

*May I, again please *

suggest to follow the *Well Defined JAVA rules*, and put all JAR
archives into the ...\lib\ext\ directory, of *either* the proper JDK or
the JRE

I'm using this technique with my privte BUILD process on my Windows XP
Development Machine ...

The advantage is that you woud NOT need *any CLASSPATH Modifications &/
Additions at all* ;-)

I'm including here my private build.bat, for the Rexx2Nrx vs. 7 RUNTIME
package, as a short sample:

=============================================================================
rem Ms DOS Batch file to build the
org.netrexx.thsitc.runtime.compatibility.jar
rem (c) [hidden email], June 2011

erase compatibility.jar
call jar.exe -cf compatibility.jar
\org\netrexx\thsitc\runtime\compatibility\META-INF\manifest.mf
call jar.exe -uf compatibility.jar
\org\netrexx\thsitc\runtime\compatibility\*.class

rem build the jar.list file for convenience
jar -vtf compatibility.jar >compatibility.jar.list

@echo release it: move jar-file to Java Run-Time ...\lib\ext\ of the SDK jre
copy compatibility.jar C:\Programme\Java\JDK1.7.0\jre\lib\ext\
=============================================================================

The pending Rexx2Nrx vs. 7 release will, however, use another
JAR-File-Name, as setup by Rene Vincent Jansen
a year ago or so, on the NETREXX Project on KENAI.

I'm still busy X-checking and updating the do's, etc, and getting
acquainted with the usage of SVN there on Kenai.

Thomas Schneider, Vienna, Austria.
-------------------------------------------------------------------------------------------------------------------------------------------
PS: my teeth extraction works quite well, only 14 still left ...

... Will then get 3d teeth start of October (this year, 2012).
...... So that I can smile agan when meeting you all at thu scheduled
next Years RexxLA Symposium ;-)
-------------------------------------------------------------------------------------------------------------------------------------------
m

Am 04.09.2012 12:07, schrieb Bill Fenlason:

> Marc, I agree - using the same folder for both nrx and java files is
> not a good idea. I said that because that might be the easiest approach.
>
> Usually Java is in a \src directory, and I'm not sure if the NetRexx
> files should be in \src or in a different directory like \nrx or
> whatever. No doubt there can be a way to have the directory names as
> user specified, and can be either different or the same in any
> combination.
>
> The current Ant build uses the \src directory for the nrx files, and
> the \build\classes directory for both the java and class files and
> copies of the nrx files.
>
> I think using \src for the nrx files, \bin for the class files and
> something like \java for the java files might be reasonable, but as I
> said, I haven't gotten into it yet. Ideally each of the three
> directory names could be user specified. (I did that with my netrexx3
> Ant task. I'm not sure if the new Ant task - written in NetRexx -
> does it that way. Rene? Kermit?)
>
> What is the most common approach used? Do most users just use \src
> for the nrx files and let the Ant build do the rest?
>
> From an Eclipse standpoint, I think having the java and class files in
> the same directory is not a good idea - the Eclipse convention is \src
> and \bin but I think they can be user specified.
>
> On 9/4/2012 4:36 AM, Marc Remes wrote:
>> On 09/03/2012 01:21 PM, Bill Fenlason wrote:
>>> The differences would probably be to include both the nrx and java
>>> files in the src directory structure and the use of
>>> the bin directory for the class files rather than the build
>>> directory structure.
>>
>> I am a bit opposed to have real source files and generated ones in
>> the same directory.
>
> _______________________________________________
> 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

ThSITC

Re: Eclipse compiler and NetRexx build

In reply to this post by billfen

May I, please, Underline Bill's suggestion *below* as a standard ?

I will now change my directory structures to follow this suggestion.

Thomas.

PS: Would be easier if&when all NetRexx Appls would use the same
conventions, I think.

Rene, please discuss with Netrexx Board and come up with a final
suggestion for the *standards*
to be used on www.Netrexx.org (Recommended Standard, of course, only,
*no MUST BE*)

Bye.
Thomas..
=============================================================
Am 04.09.2012 12:07, schrieb Bill Fenlason:

Thomas Schneider, Vienna, Austria (Europe) :-)

www.thsitc.com
www.db-123.com

Kermit Kiser

Re: Eclipse compiler and NetRexx build

In reply to this post by billfen

Bill --

I am not quite sure what you wish to accomplish here. Is this about
incremental changes and testing for the compiler/runtime modules? A
complete build including javadocs only takes 18 seconds on my dev box so
I have not seen any real need for that personally. Here is my view on
some of this stuff for what it is worth:

I don't know why the \src directory is used other than legacy and
clarity of purpose. The name is irrelevant to the build as long as the
Ant build.xml knows what it is. \nrx would work fine if there is some
important need to change it.

The build uses the \build\classes directory only to generate the
distribution jar files and the javadoc files. The nrx files don't really
need to be kept there for that phase and the whole directory should
probably be deleted at the end of the build unless someone really wants
to go back and look at the generated Java code for some reason. In fact
the whole \build directory is only a temporary structure to make it easy
to construct distribution packages for the end users.

Why do you want to save the java and class files after the compiler and
runtime jars and the javadocs have been built from them? BTW - the new
NetRexx coded Ant task does include your enhancement to specify
different directory names for the different file types but it was not
used in the build in order to remain compatible with earlier versions.

There is room for changes in the build if that can help any of our
language/compiler developers who want to use Eclipse but I don't think
it makes any difference to most NetRexx programmers.

-- Kermit

On 9/4/2012 12:07 AM, Bill Fenlason wrote:

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

billfen

Re: Eclipse compiler and NetRexx build

In reply to this post by rvjansen

Rene,

Thanks for describing your perspective.

On 9/4/2012 2:39 PM, René Jansen wrote:
> Hi Bill,
>
> I am afraid you are still speaking about home machines here; these are not the problem, as long as you can find the compiler and sometimes some other classes; ' in the wild' there are a lot of machines that have a JRE and no JDK. This is driven by the need to execute Java programs; the JRE is sufficient for that and for that reason a JRE and no JDK is installed. You are correct that the SDK is a better solution, in the sense that it installs a number of tools that you might want to use while developing - none of which is required for compiling a NetRexx program, which is our core business.
Right you are - being retired for 16+ years tends to change ones outlook
regarding machines. I do this for fun and to keep my aging brain active :)
> The first reason we cannot do this is the Oracle license agreement. We might bundle OpenJDK stuff but that is out of scope for the moment, for the other reason. The other reason is size.
Thanks for answering my question regarding this - makes sense. Although
the 10 megabyte difference in size between the tools jar and the ecj jar
doesn't seem that significant to me. Are you sure that redistribution
of the tools jar is prohibited? I don't doubt it.
> Not being able to install Eclipse sometimes has nothing to do with the capacity - some of my customers have thousands of shiny new I7's with 4GB that are exceptionally well locked down. I personally have Eclipse on all my macs, in mountable partitions because of the poor product planning for running several versions. One of them is even dedicated to testing your Eclipse plugin (and on my macs several Linux VM's with Eclipse versions for WAS maintenance, Rational dev environments, MQ Explorer, et cetera).
I'm glad to hear that you actively install Eclipse, but I'm not sure I
understand your comment about poor product planning? I have all the
Eclipse versions from 3.4.0 through 4.2.0 installed on my home machine
for testing and have no problems with various versions. The only
problem I ever had was mixing workspaces with different versions, but
that is trivial to get around.
> Your suspicion about the consequences of not being able to install the prereqs for NetRexx for the installation of NetRexx itself is incorrect. NetRexx is a jar, and a binary upload to a part of a file system of a JVM equiped computer that you have write authorization to suffices to enable compilation of source code - now that we have ecj bundled. "Installation" in the sense of adding software packages to a system entails sometimes adding to registries or component/shared libraries/dll asset repositories, all of which are controlled in modern environments. Funny that you mention Windows, where the space in the pathnames probably causes 90% of all 'javac not found' errors. And the problems you have with installing software on a phone are the same as the ones you encounter on a mainframe: try to use Java GUI without a working X client or VNC server, and try to use distributed Eclipse when you do not control the company firewall.
I would have suspected that if a company locks down their systems, they
do not allow the installation of either jars or executable binaries.
Since I have been primarily a home user for so long, I'll take your word
for it, but some actual statistics would be interesting.
> And I did notice the proclivity toward Eclipse for Android; but unless I can have a command line toolchain I am not going to do it; I make my own choices on where to waste my time and unless it is paid for I am not going to spend it on ever-changing dialog boxes and debugging configurations of changing versions of it.
Obviously you have had some bad experiences with Eclipse and perhaps
other IDE's. I think an obsession with the command line approach
inhibits "work smart, not hard", but no doubt you disagree, and you are
certainly not alone with that view. Sometimes change, even for the
better, is difficult depending on ones experience and personality.

> I respect and encourage you to enable Eclipse debugging for NetRexx. Last time I have used that is in 2003 on NetBeans and I remember the source line fixups for NetRexx in the generated class work very well; it is just not for me, because the debuggers are so slow - what I can find (the type of errors that I am prone to commit) in 5 seconds using trace I can't do in 5 minutes in a GUI debugger; I am of the type that scripts gdb because of aversion of repetitive movements. And debugging server based code in a GUI enters a whole different dimension - starting with finding the right JVM options for remote debugging (oops. the remote JVM is a different brand/release/patch then your local JVM - oops the firewall does block the rmi ports) - I am so grateful for trace that I probably can be blackmailed by people threatening to take it out.
To each his own, but in what way are the debuggers slow? In the JDE, if
I have a problem with something, I can set breakpoints instantly by
clicking on the code lines, hit F11 to debug, trace the flow, look at
variables, call stacks, etc. Then if needed, print statements can be
used. Many times I can make source changes (hot fix) and not even stop
the execution - just pause it. The bottom line is that using print /
trace statements is just a small subset of what can be done with a
graphical debugger. Are you so sure that you aren't missing something?
It's a lot easier to just use a shovel that it is to learn how to drive
a bulldozer :), and the same goes for code development as well as
debugging. If Eclipse and NetBeans are on the wrong track, why are they
so widely used?
> So enabling the compiling of NetRexx on JRE only machine, non-graphical environments does not have any consequence for the acceptance of Eclipse on admin-equiped Windows machines with working Java GUI's - it is enabling those other environments. And the Windows environments that don't work. I think the best strategy to promote Eclipse is to make a working, one size fits all plugin that people can download and use right away. When it is kept up to date with the NetRexx releases (and Eclipse releases), it might truly the best solution for this segment of the market. We do miss the manpower to do that currently, and I hope you are on board to assist with that.
I hadn't totally appreciated the importance of compiling NetRexx on JRE
only machines - the user can just interpret in some cases. But I see
the point now, and agree.

I'm not sure what you mean about the plugin and releases - Eclipse
releases occur every 4 months, and each release of my plugin runs on all
the prior versions of Eclipse starting with 3.4.2 (Feb 2009). The Latest
Juno (4.2.0 June 2012) release will work on all those 11 Eclipse
releases - I test to make sure :), and will contain the latest NetRexx
jars. Naturally I can't guarantee that any existing version will work
for all future Eclipse releases, but so far so good and downloading the
latest plugin version always works for release 3.4.2 and all later
ones. (Although 3.4 is pretty old and I may move up to 3.5).

As for "download and use right away", certainly the downloading and
installation cannot be any easier: three clicks and the word "NetRexx"
(plus the license approval sequence).

What do you suggest I do that I'm not doing?

> best regards,
>
> René.
>
> On 4 sep. 2012, at 16:08, Bill Fenlason <[hidden email]> wrote:
>
>> Thanks for the clear explanation. Isn't it possible to bundle the JDK compiler as well as the Eclipse version? I suspect the JDK is much more than javac.
>>
>> As for Eclipse installation - I sometimes run it on my NetBook - an Asus Eee - a bit old and slow but quite workable, even for development with JDK and all. Surely you can install Eclipse on your Mac or Macbook? I see that you can even install it on an iPad, and no doubt on other tablets as well.
>>
>> I suspect that if one can't install the pre-recs for NetRexx, then one can't install NetRexx either. The last I knew, the elephant in the room is still Windows and not X, unless of course you want to install the compiler on a phone.
>>
>> If you are into Android programming, perhaps you have noticed that the ADK is somewhat slanted toward Eclipse.
>>
>> On 9/4/2012 9:29 AM, rvjansen wrote:
>>> Bill,
>>>
>>> I saw your question, but time was lacking earlier to properly answer it,
>>>
>>> The intent is to enable compilation on JRE-only systems. It could have been any other compiler, but the one from Eclipse is the best I found, and combined with the licensing options it was the one that was chosen for inclusion in the package.
>>>
>>> This choice should not be construed as to be that this advantage is that you can use the Eclipse compiler without having to use the IDE. On the contrary, the systems that are in the target set for this solution, with only a JRE available, would be greatly overlapping the set where it would be impossible to install an Eclipse IDE - restrictions on running an X server to see the IDE, rules for debuggers being available; firewalls that open only certain ports; etc.
>>>
>>> For simple statistics, I have access to about 6 or 7 machines and about 10 VM's in which I could install full Eclipse and/or Java SDK. Most of these are in my home. There are at the moment around 6500 servers professionally available to me which have only a JRE (but all the same patch level and centrally managed) and no X - so no swing or awt or gwt. Or on z/OS or z/VM, you might not be the sysprog allowed to install the Java SDK.
>>>
>>> An added advantage, and an investment into the future, is that we can now support people who have an SDK and full admin access to their box, but whose NetRexx installation cannot find the (deprecated) compiler class archive. We can now point them or (the investment is towards) the installer to a working, bytecodes and class files producing compiler.
>>>
>>> So, there is no advantage to use the Eclipse Java Compiler without the IDE in itself. But, I hope that you see that there is a clear advantage in being able to compile NetRexx code when you cannot install Eclipse or the SDK, or cannot find the SDK component you need.
>>>
>>> best regards,
>>>
>>> René.
>>>
>>>
>>> On 2012-09-04 13:42, Bill Fenlason wrote:
>>>> Given time and effort, an Eclipse wizard for NetRexx projects could
>>>> solve the problems by allowing any combination of nrx, java and class
>>>> files and directories, with the default being nrx and java in the \src
>>>> directory and classes in the \bin directory.
>>>>
>>>> One long range goal is to integrate NetRexx into the Eclipse
>>>> debugger. I think that being able to specify breakpoints directly in
>>>> NetRexx source could be quite useful, as well as being able to use the
>>>> many other features of the Eclipse debugger. Trace and Print
>>>> statements will always have their place, but a sophisticated debugger
>>>> can sometimes save a lot of time.
>>>>
>>>> And I still don't understand what the advantage of using the Eclipse
>>>> compiler without the Eclipse IDE is.
>>>>
>>>>
>>>> On 9/4/2012 7:11 AM, Marc Remes wrote:
>>>>> Don't get me wrong René, I'm for peaceful coexistence as well ;
>>>>>
>>>>> On my Indigo eclipse installation, the default directories for a Java project are /src for java files and /bin for class files. Both are configurable.
>>>>> I think it is best to keep those as is and use the /src directory also for netrexx source files. The netrexx source files would compile to a /generated-java directory from where the class files would be built to the /bin directory.
>>>>>
>>>>> That way we can combine both java files and netrexx in the same project. And it's most compatible with existing.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

billfen

Re: Eclipse compiler and NetRexx build

In reply to this post by Kermit Kiser

Kermit,

Basically what I want is for it to be easy for an Eclipse or NetBeans
IDE user to be able to download the netrexxc source and immediately be
able to take advantage of the IDE.

For Eclipse that means automatic builds. (18 seconds doesn't sound long,
but I think it is quite long compared to none.) And it also means
immediate use of the Java Development Environment (JDE) and debugger for
the Java code. The whole point of Eclipse is immediate feedback,
without the need to stop and do builds. Everything in the project is up
to date, all the time.

As a current JDE example, suppose you have a method in one Java module,
and calls to that method from several of the dozens of other Java
modules in the project. Suppose you change the method to add a
parameter. What happens when you click C-s to save the file? You are
told instantly exactly which other modules have to be changed because
error messages are displayed in the "Problems" window.

All you have to do to edit those instances is to click on each error
message - a new edit window takes you there. When the call is fixed,
the error message goes away. Then when that is done, click F11 to run
or debug the program.

How does the JDE accomplish that? Obviously all the Java source and
classes are kept around and the compiles and build are done
automatically and constantly with every change.

What I want to do in the long run is to provide the same kind of
development environment for NetRexx code.

Here is another example. As an Eclipse user, you want to develop a test
version of the compiler. Here are the only steps that should be
necessary: Type in the SVN repository name, and download the Eclipse
project for netrexxc. Open RxTranslator.nrx to edit it. Modify the
banner (logo) message. C-s to save the file. Open Hello.nrx. Click
interpret or compile (with new compiler) to test the change. The new
banner is displayed in the console window (before "hello").

No other steps should be necessary - no builds - just immediate !
results. Then if there is a misspelled word in the new banner, all that
has to be done is to change it - that souce file is still open, etc.,
and if a syntax error is made, you know immediately, (it is underlined)
and you don't even have to save the file.

Except for the download, you could probably do the whole thing in less
than 18 seconds.

And if you are a developer, all you have to do is click "team" and then
"commit" and "OK", and you are done.

On 9/4/2012 8:23 PM, Kermit Kiser wrote:

> Bill --
>
> I am not quite sure what you wish to accomplish here. Is this about
> incremental changes and testing for the compiler/runtime modules? A
> complete build including javadocs only takes 18 seconds on my dev box
> so I have not seen any real need for that personally. Here is my view
> on some of this stuff for what it is worth:
>
> I don't know why the \src directory is used other than legacy and
> clarity of purpose. The name is irrelevant to the build as long as the
> Ant build.xml knows what it is. \nrx would work fine if there is some
> important need to change it.
>
> The build uses the \build\classes directory only to generate the
> distribution jar files and the javadoc files. The nrx files don't
> really need to be kept there for that phase and the whole directory
> should probably be deleted at the end of the build unless someone
> really wants to go back and look at the generated Java code for some
> reason. In fact the whole \build directory is only a temporary
> structure to make it easy to construct distribution packages for the
> end users.
>
> Why do you want to save the java and class files after the compiler
> and runtime jars and the javadocs have been built from them? BTW - the
> new NetRexx coded Ant task does include your enhancement to specify
> different directory names for the different file types but it was not
> used in the build in order to remain compatible with earlier versions.
>
> There is room for changes in the build if that can help any of our
> language/compiler developers who want to use Eclipse but I don't think
> it makes any difference to most NetRexx programmers.
>
> -- Kermit
>
>
> On 9/4/2012 12:07 AM, Bill Fenlason wrote:
>> Marc, I agree - using the same folder for both nrx and java files is
>> not a good idea. I said that because that might be the easiest
>> approach.
>>
>> Usually Java is in a \src directory, and I'm not sure if the NetRexx
>> files should be in \src or in a different directory like \nrx or
>> whatever. No doubt there can be a way to have the directory names as
>> user specified, and can be either different or the same in any
>> combination.
>>
>> The current Ant build uses the \src directory for the nrx files, and
>> the \build\classes directory for both the java and class files and
>> copies of the nrx files.
>>
>> I think using \src for the nrx files, \bin for the class files and
>> something like \java for the java files might be reasonable, but as I
>> said, I haven't gotten into it yet. Ideally each of the three
>> directory names could be user specified. (I did that with my
>> netrexx3 Ant task. I'm not sure if the new Ant task - written in
>> NetRexx - does it that way. Rene? Kermit?)
>>
>> What is the most common approach used? Do most users just use \src
>> for the nrx files and let the Ant build do the rest?
>>
>> From an Eclipse standpoint, I think having the java and class files
>> in the same directory is not a good idea - the Eclipse convention is
>> \src and \bin but I think they can be user specified.
>>
>> On 9/4/2012 4:36 AM, Marc Remes wrote:
>>> On 09/03/2012 01:21 PM, Bill Fenlason wrote:
>>>> The differences would probably be to include both the nrx and java
>>>> files in the src directory structure and the use of
>>>> the bin directory for the class files rather than the build
>>>> directory structure.
>>>
>>> I am a bit opposed to have real source files and generated ones in
>>> the same directory.
>>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

123