NetRexx installation revisited

[Thomas.Schneider.Wien]

Hi Patrick,
   thanks a LOT for this valuable methodology mentioned below.
(I did also change the subject, by the way ...)
Tom.
================================================
Patric Bechtel schrieb:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi René,
>
> the rt.jar location could probably be parsed out of the url by asking
> for a well-known resource like "/java/lang/String.class", the path is
> before the exclamation mark, just like this:
>
> say String.class.getResource('/java/lang/String.class')
>
> gives
>
> jar:file:/usr/lib/jvm/jdk1.6.0_18/jre/lib/rt.jar!/java/lang/String.class
>
> :-)
>
> Patric
>
> René Jansen schrieb am 15.03.2010 11:15:
>  
>> Patric,
>>
>> thanks for this valuable pointer. OTOH, NetRexx has already impressive
>> bytecode generation features in the interpreter part; as always, it is
>> about carefully introducing or leaving out dependencies.
>>
>> I had a look at the Eclipse JDT - it requires one to speficy a Java
>> rt.jar - it would solve the JRE problem but not all the location
>> problems. Next thing I am going to look at is the source of javac -
>> the launcher, not the Java compiler part, and see what that has to
>> offer in terms of inspiration.
>>
>> best regards,
>>
>> René.
>>
>> On Mon, Mar 15, 2010 at 4:05 AM, Tom Maynard <[hidden email]> wrote:
>>    
>>> Patric Bechtel wrote:
>>>
>>> - - using the JDT compiler instead of relying upon the javac compiler (and
>>> on the user installing a jdk instead of the mostly preinstalled jre).
>>> The JDT compiler is very compact and would enable a "instant on"
>>> experience for the user.
>>>
>>>
>>>
>>> Another option to consider: Janino.  From the webpage:
>>>
>>> Janino is a compiler that reads a JavaTM expression, block, class body,
>>> source file or a set of source files, and generates JavaTM bytecode that is
>>> loaded and executed directly. Janino is not intended to be a development
>>> tool, but an embedded compiler for run-time compilation purposes, e.g.
>>> expression evaluators or "server pages" engines like JSP.
>>>
>>> JANINO is integrated with Apache Commons JCI ("Java Compiler Interface") and
>>> JBoss Rules / Drools.
>>>
>>> JANINO can also be used for static code analysis or code manipulation.
>>>
>>> The webpage is http://docs.codehaus.org/display/JANINO/Home.  Otherwise I
>>> have no knowledge or experience with the application.  I'm just keeping the
>>> group's options open (I hope).
>>>
>>> Tom.
>>>
>>>      
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: GnuPT 2.5.2
>
> iEYEARECAAYFAkueFn8ACgkQfGgGu8y7ypAnrwCePJp4RwpCGDcGweSVDNxk6w05
> bycAoIICT1M5efx5JHS2RZTXvSMJy0FS
> =YGTK
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>
>  

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[measel]

Folks, for the passerby don't install anything!  Webstart the jar file mentioned earlier.
Put the "compiler server" that someone has already written up as an amazon app and be done with this conversation.

<Rant> I can't stand the Adobe approach to fixing my problem - Don't litter with software!!!
</Rant>

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Patric Bechtel
Sent: Monday, March 15, 2010 6:14 AM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] NetRexx installation revisited

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi René,

the rt.jar location could probably be parsed out of the url by asking
for a well-known resource like "/java/lang/String.class", the path is
before the exclamation mark, just like this:

say String.class.getResource('/java/lang/String.class')

gives

jar:file:/usr/lib/jvm/jdk1.6.0_18/jre/lib/rt.jar!/java/lang/String.class

:-)

Patric

René Jansen schrieb am 15.03.2010 11:15:

> Patric,
>
> thanks for this valuable pointer. OTOH, NetRexx has already impressive
> bytecode generation features in the interpreter part; as always, it is
> about carefully introducing or leaving out dependencies.
>
> I had a look at the Eclipse JDT - it requires one to speficy a Java
> rt.jar - it would solve the JRE problem but not all the location
> problems. Next thing I am going to look at is the source of javac -
> the launcher, not the Java compiler part, and see what that has to
> offer in terms of inspiration.
>
> best regards,
>
> René.
>
> On Mon, Mar 15, 2010 at 4:05 AM, Tom Maynard <[hidden email]> wrote:
>> Patric Bechtel wrote:
>>
>> - - using the JDT compiler instead of relying upon the javac compiler (and
>> on the user installing a jdk instead of the mostly preinstalled jre).
>> The JDT compiler is very compact and would enable a "instant on"
>> experience for the user.
>>
>>
>>
>> Another option to consider: Janino.  From the webpage:
>>
>> Janino is a compiler that reads a JavaTM expression, block, class body,
>> source file or a set of source files, and generates JavaTM bytecode that is
>> loaded and executed directly. Janino is not intended to be a development
>> tool, but an embedded compiler for run-time compilation purposes, e.g.
>> expression evaluators or "server pages" engines like JSP.
>>
>> JANINO is integrated with Apache Commons JCI ("Java Compiler Interface") and
>> JBoss Rules / Drools.
>>
>> JANINO can also be used for static code analysis or code manipulation.
>>
>> The webpage is http://docs.codehaus.org/display/JANINO/Home.  Otherwise I
>> have no knowledge or experience with the application.  I'm just keeping the
>> group's options open (I hope).
>>
>> Tom.
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: GnuPT 2.5.2

iEYEARECAAYFAkueFn8ACgkQfGgGu8y7ypAnrwCePJp4RwpCGDcGweSVDNxk6w05
bycAoIICT1M5efx5JHS2RZTXvSMJy0FS
=YGTK
-----END PGP SIGNATURE-----
_______________________________________________
Ibm-netrexx mailing list
[hidden email]



_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

In the discussion bellow the term classpath is used in 2 distinct meanings:

"CLASSPATH" (in upper-case) is meant as an environment variable hinting the jre
which actual logical "classpath" (in lower-case) to use while trying to load classes.

- the people who know Java and their platform;
- the people coming from other Rexxen trying out the promise of the world of the Java VM and its standardized class libraries;
- passers-by maybe entering the world of programming or maybe disillusioned by the runtime performance of jruby and jpython (we have to work on that ;-))
  

I only see 2 groups.

"Passers-by entering the world of programming" not willing to invest
half an our reading some set-up instructions are not going to program
anything of any interest, in any language... ever! These should not
be our target audience.

As often is the case, the requirements and needs of these are different. People coming from Java (like myself, I did some Java before discovering NetRexx through Ed Tomlinson's Pipes for NetRexx package, but with earlier Rexx experience on MVS, OS/2 and NT) generally have no issues, drop the jar somewhere, edit the classpath and go. After some reflection and re-reading of past messages I now do agree that the first group does not need to be catered for at all, but the others do. The second group can be catered for with correct and elaborate instructions. My worries here concern the last mentioned group, the passers-by. I am passing by a lot of languages and compilers, and the number one put-off to try and install some compiler is a long list of instructions - there is even some equation in which the lenght of the instruction lists is equal to the failure rate.
  

Yes, programming is not easy. I agree it is not a thing for everyone.
Are we really trying to build a pedagogical programming language to
get the 5% people who actually become programmers at some point move
to some other "real language" latter?

Thus my proposal would be to have only a modest set of instructions added to the distribution archive; split up in separate pdf files for every major platform (Wintel, Linux-x86, Linux-Z, Aix, MacOSX). The 'elaborate sets' should be in the wiki on www.netrexx.org and linked to from these documents - Chip's excellent instruction/verification text should go in there.
  

I agree Chip made an excellent job. Some issues remain IIRC as there
was some hard-coded path in his batch file though.

The passers-by need to be catered for, if only because in the literature describing the history of Rexx, parallells with BASIC and Logo are drawn. We can say what we want about BASIC, the line numbered version, but it has attained its goal of enabling novices to program, and Logo is, I heard, even teachable to 5-years old (although I suspect that would be the crawling turtle part, not the recursive list hierarchy transversal part).
  

I learnt how to program in a CBM 64 using BASIC indeed. Many of my friends
also tried at the time. Most of them never got past:

10 PRINT"MY BROTHER IS AN AS*H*LE"
20 GOTO10

Some even reached

10 X$=0
20 X$=X$+1:PRINTX$;"MY BROTHER IS AN AS*H*LE"
30 GOTO20

The rest spent a lot of time studying memory maps, learning how to call kernal
routines, etc. Then moved to 6502 assembler as soon as we could. Here "the rest"
& "we" includes just me, what's the point in enabling my aunt Rosario writing a
hello-world program at all?

The fact is that programming requires some learning effort. That's true even when
trying to program your VCR or washing machine.

Different OS platforms have different strategies for the placement of the standard platform JVM (if any), (several) different JVM's can be installed on a platform, and some users may even switch JVMs during the development cycle, for example for the purpose of regression testing. The effects of the combination of, for example, a heterogeneous set of shared libraries and java archives can range from unnoticed to bewildering, to catastrophic.
  

I guess people with such a "complex" jvm set-up are coming from your first group:
the one not experiencing any trouble setting the classpath right :-)

I think the principles on which we base the solutions for the encountered problems, must be to use environmental platform clues as much as possible, and the NetRexx translator itself must be very sparingly (and always relative to the environmental hint) guess where the correct libraries are. Even on MacOSX, where the Java locations were fixed for years, I am encountering two movements: the Apple team thinking of alternative packaging structure, moving eventually to mainstream *nix conventions, and in the meantime offering a program to locate the JAVA_HOME; and the open source Sun JDK7 releases being used as an alternative for people experimenting with InvokeDynamic, tail recursion and other great things to come to the JVM.

A subject of discussion is the use of the standard 'blessed' extension directories: they were not always there, they seem to multiply on some platforms, they might work differently among JVM vendors, and I see a high incidence of trouble with people using them. I do not have any problem with a user preference for their use, only I am loathe to advice to use them in the standard install document when this does not turn out to be a totally dependable mechanism. As a side thought - it might hinder understanding of the classpath model, which leads to trouble with the first application that is not in the default package.
  

I think is time for all of us to forget about both CLASSPATH and extensions directories
once for all.
These just add complexity to an actually simple subject:

When you compile something in any language, you tell your compiler where to find
needed libraries and or components. In java (and in NetRexx) this is done by
specifying a classpath at the command line. In fact it's even easier than in most
other compiled languages, where you have to cater for declarations and implementations
or binary objects separately. Yeah, that wouldn't be the case when programming your
run of the mill hello-world program...

- a package-less 'nrc' class in the jar that has a main that calls the translator for a compile, and a .manifest file that declares that main, enabling users to start a compile with 'java -jar NetRexxC.jar SourceFile[.nrx]';
- platform dependent hints in the translator, relative to a JAVA_HOME environmental setting. For the open source releases we can have minor versions that address changes on the platforms;
  

Agree that could save some typing.

- a extra System.exec('java') when the Java compiler class cannot be found (funny enough a successful Java SDK enables the javac, which is a very thin native invoker executable for a Java program, to find its compiler class)
  

Hmmm... not sure I follow you here... Wouldn't a *clear* jdk requirement save most of the
trouble people are experiencing?

One snag here is that fetching environment variables has been deprected in Java for a number of years (not every platform - phones -  have them) but since that seems to be reversed, and other language processors use them, I gather we are safe here for the future.
  

I don't think environment variables, as such, are deprecated at all. This is a system
specific thing having nothing to do with java itself . It's just CLASSPATH which has
been deprecated since at least java 2 version 1.2

For the moment, I would like to avoid a native or Java-installer approach that needs all this knowledge of platforms and possible combinations of JVM releases on machines out there. But I would certainly not oppose someone to pick this up and support this.
  

Agree this would involve platform specific code but the truth is that NetRexx
today is being distributed with platform specific non-working scripts!

Here is my proposal:

- Distribute NetRexx with working scripts just dependent on a couple environment
  variables. Say NRX_HOME and NRX_JDK.
- Bundle a simple NrxInstall package-less class in the main NetRexxC.jar
- Instruct the user to type "java -cp NetRexxC.jar NrxInstall

This would just ask 2 questions to the user:

- ¿Where is your jdk installed?

  A check is done for an actual jdk install there. If not present, we ask again.
  Some intelligence could be built in as to a tries to automatically find an
  installed jdk.

- ¿Where do you want to install NetRexx?

  This defaults to where NetRexxC.jar is located for this execution of NrxInstall. We
  already have this information from the command line. If user changes this, then we
  copy NetRexxC.jar to desired location.

Finally NrxInstall intructs the user to put the second directory in his PATH if he
wants to save some typing and what command to type if he does not.

That's it. Rerun this every time you mess with your java environment.

Honestly, this takes so much more to explain than to do. I would already have done
it if I had had the time. Just too many balls airborne at once :-)

A separate 'Building applications for NetRexx' document, should contain chapters on package and directory structure, and touch subjects like the use of 'make', 'ant' and 'maven', class-in-source or not, generating Javadoc, how to handle dependencies, etc. On a side thought, 

Yeah, a Developers Guide would be great!

I wonder if our planned cpan-like repository could be a maven repository. The 'Building' document should explain about how to structure for NetRexx web apps using J2EE packaging conventions for JBoss, Glassfish and WebSphere. Obviously I would welcome volunteers to start building this information.
  

Hmm... not sure. Developing suitable Netbeans and Eclipse plugins for NetRexx would cover
95% of this. And it would help raise mainstream NetRexx awareness sooo muuch more!

Please let me know what you think - I already know that we would like the open source release to happen soon - but we can do so much as a community already before that happens. 

Fully agree

I will try to have the wiki up somewhere this weekend. It will be a JSPWiki, not the slickest around, but it enables us to extend it and brand the site NetRexx - powered. It will probably start out with three projects on it - installation, building and IDE - but even the table of contents will be user-editable.
  

That is great news indeed.



_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Patric Bechtel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

my tips here wasn't meant just for "passers-by", whatever that is.

Java *can* be a pain in the butt when it comes to classpath hell. To
ease that pain or, in terms of NetRexx newbies, I think it would be nice
to have a smooth language experience. Especially, if NetRexx is your
first contact to Java; in that case, every bad experience with Java will
be a bad experience of "NetRexx", the newbies cannot tell the culprit.

My fear is, that, if you use another language for the first time, you
get "wrapped" into an IDE, so most of these issues are solved there.
NetRexx doesn't have an IDE (I wouldn't call jEdit, which is my
favourite editor for almost a decade already, an IDE), and that will be
the case for quite some time.

Anyway, I don't like IDE's, and the elegance of having a small download
and an instant "see, it works" experience has much of an exciting moment
for a newbie. Especially when putting your first program to another
machine, maybe with on OS you're not an expert, and it just works there,
too.

What I would like to see in near future is something like the scala or
groovy interactive shell, which make testing and playing so much easier,
even for profs like me.

just my 0.02?...

Patric

David Requena schrieb am 15.03.2010 13:30:

> In the discussion bellow the term classpath is used in 2 distinct meanings:
>
> "CLASSPATH" (in upper-case) is meant as an environment variable hinting
> the jre
> which actual logical "classpath" (in lower-case) to use while trying to
> load classes.
>
>> - the people who know Java and their platform;
>> - the people coming from other Rexxen trying out the promise of the world of the Java VM and its standardized class libraries;
>> - passers-by maybe entering the world of programming or maybe disillusioned by the runtime performance of jruby and jpython (we have to work on that ;-))
>>  
>
> I only see 2 groups.
>
> "Passers-by entering the world of programming" not willing to invest
> half an our reading some set-up instructions are not going to program
> anything of any interest, in any language... ever! These should not
> be our target audience.
>
>> As often is the case, the requirements and needs of these are different. People coming from Java (like myself, I did some Java before discovering NetRexx through Ed Tomlinson's Pipes for NetRexx package, but with earlier Rexx experience on MVS, OS/2 and NT) generally have no issues, drop the jar somewhere, edit the classpath and go. After some reflection and re-reading of past messages I now do agree that the first group does not need to be catered for at all, but the others do. The second group can be catered for with correct and elaborate instructions. My worries here concern the last mentioned group, the passers-by. I am passing by a lot of languages and compilers, and the number one put-off to try and install some compiler is a long list of instructions - there is even some equation in which the lenght of the instruction lists is equal to the failure rate.
>>  
>
> Yes, programming is not easy. I agree it is not a thing for everyone.
> Are we really trying to build a pedagogical programming language to
> get the 5% people who actually become programmers at some point move
> to some other "real language" latter?
>
>> Thus my proposal would be to have only a modest set of instructions added to the distribution archive; split up in separate pdf files for every major platform (Wintel, Linux-x86, Linux-Z, Aix, MacOSX). The 'elaborate sets' should be in the wiki on www.netrexx.org and linked to from these documents - Chip's excellent instruction/verification text should go in there.
>>  
>
> I agree Chip made an excellent job. Some issues remain IIRC as there
> was some hard-coded path in his batch file though.
>
>> The passers-by need to be catered for, if only because in the literature describing the history of Rexx, parallells with BASIC and Logo are drawn. We can say what we want about BASIC, the line numbered version, but it has attained its goal of enabling novices to program, and Logo is, I heard, even teachable to 5-years old (although I suspect that would be the crawling turtle part, not the recursive list hierarchy transversal part).
>>  
>
> I learnt how to program in a CBM 64 using BASIC indeed. Many of my friends
> also tried at the time. Most of them never got past:
>
> 10 PRINT"MY BROTHER IS AN AS*H*LE"
> 20 GOTO10
>
> Some even reached
>
> 10 X$=0
> 20 X$=X$+1:PRINTX$;"MY BROTHER IS AN AS*H*LE"
> 30 GOTO20
>
> The rest spent a lot of time studying memory maps, learning how to call
> kernal
> routines, etc. Then moved to 6502 assembler as soon as we could. Here
> "the rest"
> & "we" includes just me, what's the point in enabling my aunt Rosario
> writing a
> hello-world program at all?
>
> The fact is that programming requires some learning effort. That's true
> even when
> trying to program your VCR or washing machine.
>
>> Different OS platforms have different strategies for the placement of the standard platform JVM (if any), (several) different JVM's can be installed on a platform, and some users may even switch JVMs during the development cycle, for example for the purpose of regression testing. The effects of the combination of, for example, a heterogeneous set of shared libraries and java archives can range from unnoticed to bewildering, to catastrophic.
>>  
>
> I guess people with such a "complex" jvm set-up are coming from your
> first group:
> the one not experiencing any trouble setting the classpath right :-)
>
>> I think the principles on which we base the solutions for the encountered problems, must be to use environmental platform clues as much as possible, and the NetRexx translator itself must be very sparingly (and always relative to the environmental hint) guess where the correct libraries are. Even on MacOSX, where the Java locations were fixed for years, I am encountering two movements: the Apple team thinking of alternative packaging structure, moving eventually to mainstream *nix conventions, and in the meantime offering a program to locate the JAVA_HOME; and the open source Sun JDK7 releases being used as an alternative for people experimenting with InvokeDynamic, tail recursion and other great things to come to the JVM.
>>
>> A subject of discussion is the use of the standard 'blessed' extension directories: they were not always there, they seem to multiply on some platforms, they might work differently among JVM vendors, and I see a high incidence of trouble with people using them. I do not have any problem with a user preference for their use, only I am loathe to advice to use them in the standard install document when this does not turn out to be a totally dependable mechanism. As a side thought - it might hinder understanding of the classpath model, which leads to trouble with the first application that is not in the default package.
>>  
>
> I think is time for all of us to forget about both CLASSPATH and
> extensions directories
> once for all.
> These just add complexity to an actually simple subject:
>
> When you compile something in any language, you tell your compiler where
> to find
> needed libraries and or components. In java (and in NetRexx) this is done by
> specifying a classpath at the command line. In fact it's even easier
> than in most
> other compiled languages, where you have to cater for declarations and
> implementations
> or binary objects separately. Yeah, that wouldn't be the case when
> programming your
> run of the mill hello-world program...
>
>> - a package-less 'nrc' class in the jar that has a main that calls the translator for a compile, and a .manifest file that declares that main, enabling users to start a compile with 'java -jar NetRexxC.jar SourceFile[.nrx]';
>> - platform dependent hints in the translator, relative to a JAVA_HOME environmental setting. For the open source releases we can have minor versions that address changes on the platforms;
>>  
>
> Agree that could save some typing.
>
>> - a extra System.exec('java') when the Java compiler class cannot be found (funny enough a successful Java SDK enables the javac, which is a very thin native invoker executable for a Java program, to find its compiler class)
>>  
>
> Hmmm... not sure I follow you here... Wouldn't a *clear* jdk requirement
> save most of the
> trouble people are experiencing?
>
>> One snag here is that fetching environment variables has been deprected in Java for a number of years (not every platform - phones -  have them) but since that seems to be reversed, and other language processors use them, I gather we are safe here for the future.
>>  
>
> I don't think environment variables, as such, are deprecated at all.
> This is a system
> specific thing having nothing to do with java itself . It's just
> CLASSPATH which has
> been deprecated since at least java 2 version 1.2
>
>> For the moment, I would like to avoid a native or Java-installer approach that needs all this knowledge of platforms and possible combinations of JVM releases on machines out there. But I would certainly not oppose someone to pick this up and support this.
>>  
>
> Agree this would involve platform specific code but the truth is that
> NetRexx
> today is being distributed with platform specific non-working scripts!
>
> Here is my proposal:
>
> - Distribute NetRexx with working scripts just dependent on a couple
> environment
>   variables. Say NRX_HOME and NRX_JDK.
> - Bundle a simple NrxInstall package-less class in the main NetRexxC.jar
> - Instruct the user to type "java -cp NetRexxC.jar NrxInstall
>
> This would just ask 2 questions to the user:
>
> - ¿Where is your jdk installed?
>
>   A check is done for an actual jdk install there. If not present, we
> ask again.
>   Some intelligence could be built in as to a tries to automatically find an
>   installed jdk.
>
> - ¿Where do you want to install NetRexx?
>
>   This defaults to where NetRexxC.jar is located for this execution of
> NrxInstall. We
>   already have this information from the command line. If user changes
> this, then we
>   copy NetRexxC.jar to desired location.
>
> Finally NrxInstall intructs the user to put the second directory in his
> PATH if he
> wants to save some typing and what command to type if he does not.
>
> That's it. Rerun this every time you mess with your java environment.
>
> Honestly, this takes so much more to explain than to do. I would already
> have done
> it if I had had the time. Just too many balls airborne at once :-)
>
>
>> A separate 'Building applications for NetRexx' document, should contain chapters on package and directory structure, and touch subjects like the use of 'make', 'ant' and 'maven', class-in-source or not, generating Javadoc, how to handle dependencies, etc. On a side thought,
>
> Yeah, a Developers Guide would be great!
>
>> I wonder if our planned cpan-like repository could be a maven repository. The 'Building' document should explain about how to structure for NetRexx web apps using J2EE packaging conventions for JBoss, Glassfish and WebSphere. Obviously I would welcome volunteers to start building this information.
>>  
>
> Hmm... not sure. Developing suitable Netbeans and Eclipse plugins for
> NetRexx would cover
> 95% of this. And it would help raise mainstream NetRexx awareness sooo
> muuch more!
>
>> Please let me know what you think - I already know that we would like the open source release to happen soon - but we can do so much as a community already before that happens.
>
> Fully agree
>
>> I will try to have the wiki up somewhere this weekend. It will be a JSPWiki, not the slickest around, but it enables us to extend it and brand the site NetRexx - powered. It will probably start out with three projects on it - installation, building and IDE - but even the table of contents will be user-editable.
>>  
>
> That is great news indeed.
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: GnuPT 2.5.2

iEYEARECAAYFAkueNy4ACgkQfGgGu8y7ypAdEgCfeUKi/AOlbOmRJDecJ2wic6/7
bJoAoLv5UaOcIKGTX1d6/sHOrLxlFVDW
=lMvn
-----END PGP SIGNATURE-----
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

El 14/03/2010 20:35, Fernando Cassia escribió:
> On Sat, Mar 13, 2010 at 11:14 AM, René Jansen<[hidden email]>  wrote:
>    
>> >  - a package-less 'nrc' class in the jar that has a main that calls the translator for a compile, and a .manifest file that declares that main, enabling users to start a compile with 'java -jar NetRexxC.jar SourceFile[.nrx]';
>>      
> This is the right and only way to do things, imho.:)
>    

Yeah, only trouble is you would need two of these (one for compiling and
one interpreting, right?)

- But you can only have one main class in a jar's manifest. Oh...
- then we could pass some argument to the main method but...
- then the programmer would need to type more than 10 characters in a row
- unacceptable!!

Then NetRexx programs need to be run. How the hell do we accomplish this
without somehow including
NetRexxC.jar or NetRexxR.jar in the classpath (note the lower-casing)??

by using a '-cp' commandline option of course
again...
in addition to type more than 10 chars, the user would need to remember
where did he copy the damned jar file!

I keep myself asking what's the whole point? what is the target audience?

> End users shouldn´t have to mess with the classpath. PERIOD.
>    

the classpath model is a fundamental, integral, part of the java
specification. Anyone developing for the
jvm should be either familiar with the concept or developing for some
other platform. End users of a
programming language are in fact programmers, not some computer
illiterate end user trying to load some
solitaire card game. Admitedly the latter shouldn't be forced to wrestle
the classpath. These should have
a nice icon to double click with the "pointy thing" on screen.

---
Saludos / Kind regards.
David Requena


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[rvjansen]

Patric,

yep!

  method getRuntimeJarLocation() returns java.net.URL static
    return Class.class.getResource('/java/lang/String.class')

  method getCompilerJarLocation() returns java.net.URL static
    return Class.class.getResource('/com/sun/tools/javac/main/Main.class')


jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/classes.jar!/java/lang/String.class
jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/classes.jar!/com/sun/tools/javac/main/Main.class


This will certainly help. Thank you so much.

best regards,

René.


On 15 mrt 2010, at 12:14, Patric Bechtel wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi René,
>
> the rt.jar location could probably be parsed out of the url by asking
> for a well-known resource like "/java/lang/String.class", the path is
> before the exclamation mark, just like this:
>
> say String.class.getResource('/java/lang/String.class')
>
> gives
>
> jar:file:/usr/lib/jvm/jdk1.6.0_18/jre/lib/rt.jar!/java/lang/String.class
>
> :-)
>
> Patric
>
> René Jansen schrieb am 15.03.2010 11:15:
>> Patric,
>>
>> thanks for this valuable pointer. OTOH, NetRexx has already impressive
>> bytecode generation features in the interpreter part; as always, it is
>> about carefully introducing or leaving out dependencies.
>>
>> I had a look at the Eclipse JDT - it requires one to speficy a Java
>> rt.jar - it would solve the JRE problem but not all the location
>> problems. Next thing I am going to look at is the source of javac -
>> the launcher, not the Java compiler part, and see what that has to
>> offer in terms of inspiration.
>>
>> best regards,
>>
>> René.
>>
>> On Mon, Mar 15, 2010 at 4:05 AM, Tom Maynard <[hidden email]> wrote:
>>> Patric Bechtel wrote:
>>>
>>> - - using the JDT compiler instead of relying upon the javac compiler (and
>>> on the user installing a jdk instead of the mostly preinstalled jre).
>>> The JDT compiler is very compact and would enable a "instant on"
>>> experience for the user.
>>>
>>>
>>>
>>> Another option to consider: Janino.  From the webpage:
>>>
>>> Janino is a compiler that reads a JavaTM expression, block, class body,
>>> source file or a set of source files, and generates JavaTM bytecode that is
>>> loaded and executed directly. Janino is not intended to be a development
>>> tool, but an embedded compiler for run-time compilation purposes, e.g.
>>> expression evaluators or "server pages" engines like JSP.
>>>
>>> JANINO is integrated with Apache Commons JCI ("Java Compiler Interface") and
>>> JBoss Rules / Drools.
>>>
>>> JANINO can also be used for static code analysis or code manipulation.
>>>
>>> The webpage is http://docs.codehaus.org/display/JANINO/Home.  Otherwise I
>>> have no knowledge or experience with the application.  I'm just keeping the
>>> group's options open (I hope).
>>>
>>> Tom.
>>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: GnuPT 2.5.2
>
> iEYEARECAAYFAkueFn8ACgkQfGgGu8y7ypAnrwCePJp4RwpCGDcGweSVDNxk6w05
> bycAoIICT1M5efx5JHS2RZTXvSMJy0FS
> =YGTK
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

El 14/03/2010 20:42, Fernando Cassia escribió:
> This is ridiculous and developers who do this shouldn´t be shipping
> Java apps in the first place. Yes, I´ve seen such apps, and yes, most
> of these firms have gone under, thank God. (Prismiq was one of them,
> shipping a JVM 1.4.x at the time there was a 1.5.x available with many
> less bugs).
>    

Talk to IBM about their latest editions of the Notes client or their
management consoles
for DS SAN cabinets...
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

El 15/03/2010 11:07, Thomas Schneider escribió:
> For the inexperienced user, we should try to enforce David's NetRexxDE
> and Kermit's NetRexxScript.

I hope we're not enforcing anyone on anything regarding NetRexx!!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

The fact remains that as far as the NetRexx language processor does not
produce
byte code directly, some java compiler will be needed. Be it the one
from the
standard jdk's or some other exotic one.

If that is such a big issue, why not spend the effort on the direct
bytecode generation aspect?

---
Saludos / Kind regards.
David Requena


El 15/03/2010 11:15, René Jansen escribió:

> Patric,
>
> thanks for this valuable pointer. OTOH, NetRexx has already impressive
> bytecode generation features in the interpreter part; as always, it is
> about carefully introducing or leaving out dependencies.
>
> I had a look at the Eclipse JDT - it requires one to speficy a Java
> rt.jar - it would solve the JRE problem but not all the location
> problems. Next thing I am going to look at is the source of javac -
> the launcher, not the Java compiler part, and see what that has to
> offer in terms of inspiration.
>
> best regards,
>
> René.
>
> On Mon, Mar 15, 2010 at 4:05 AM, Tom Maynard<[hidden email]>  wrote:
>    
>> Patric Bechtel wrote:
>>
>> - - using the JDT compiler instead of relying upon the javac compiler (and
>> on the user installing a jdk instead of the mostly preinstalled jre).
>> The JDT compiler is very compact and would enable a "instant on"
>> experience for the user.
>>
>>
>>
>> Another option to consider: Janino.  From the webpage:
>>
>> Janino is a compiler that reads a JavaTM expression, block, class body,
>> source file or a set of source files, and generates JavaTM bytecode that is
>> loaded and executed directly. Janino is not intended to be a development
>> tool, but an embedded compiler for run-time compilation purposes, e.g.
>> expression evaluators or "server pages" engines like JSP.
>>
>> JANINO is integrated with Apache Commons JCI ("Java Compiler Interface") and
>> JBoss Rules / Drools.
>>
>> JANINO can also be used for static code analysis or code manipulation.
>>
>> The webpage is http://docs.codehaus.org/display/JANINO/Home.  Otherwise I
>> have no knowledge or experience with the application.  I'm just keeping the
>> group's options open (I hope).
>>
>> Tom.
>>
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>
>>
>>      
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>    

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[measel]

Here is (from 2005!)  Using Java compiler in your Web Start application
http://weblogs.java.net/blog/2005/05/27/using-java-compiler-your-web-start-application

We have been running java applications with "Web Start" for some years now. It makes keeping everything tidy and always in sync even as jvms and jdks come and go.  


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of David Requena
Sent: Monday, March 15, 2010 8:54 AM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] NetRexx installation revisited


The fact remains that as far as the NetRexx language processor does not
produce
byte code directly, some java compiler will be needed. Be it the one
from the
standard jdk's or some other exotic one.

If that is such a big issue, why not spend the effort on the direct
bytecode generation aspect?

---
Saludos / Kind regards.
David Requena


El 15/03/2010 11:15, René Jansen escribió:

> Patric,
>
> thanks for this valuable pointer. OTOH, NetRexx has already impressive
> bytecode generation features in the interpreter part; as always, it is
> about carefully introducing or leaving out dependencies.
>
> I had a look at the Eclipse JDT - it requires one to speficy a Java
> rt.jar - it would solve the JRE problem but not all the location
> problems. Next thing I am going to look at is the source of javac -
> the launcher, not the Java compiler part, and see what that has to
> offer in terms of inspiration.
>
> best regards,
>
> René.
>
> On Mon, Mar 15, 2010 at 4:05 AM, Tom Maynard<[hidden email]>  wrote:
>    
>> Patric Bechtel wrote:
>>
>> - - using the JDT compiler instead of relying upon the javac compiler (and
>> on the user installing a jdk instead of the mostly preinstalled jre).
>> The JDT compiler is very compact and would enable a "instant on"
>> experience for the user.
>>
>>
>>
>> Another option to consider: Janino.  From the webpage:
>>
>> Janino is a compiler that reads a JavaTM expression, block, class body,
>> source file or a set of source files, and generates JavaTM bytecode that is
>> loaded and executed directly. Janino is not intended to be a development
>> tool, but an embedded compiler for run-time compilation purposes, e.g.
>> expression evaluators or "server pages" engines like JSP.
>>
>> JANINO is integrated with Apache Commons JCI ("Java Compiler Interface") and
>> JBoss Rules / Drools.
>>
>> JANINO can also be used for static code analysis or code manipulation.
>>
>> The webpage is http://docs.codehaus.org/display/JANINO/Home.  Otherwise I
>> have no knowledge or experience with the application.  I'm just keeping the
>> group's options open (I hope).
>>
>> Tom.
>>
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>
>>
>>      
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>    

_______________________________________________
Ibm-netrexx mailing list
[hidden email]



_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Patric Bechtel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi David,

that won't work until NetRexx is open sourced, which is some unknown
time to be. The compiler from the eclipse project is not really
experimental btw, everyone using the eclipse IDE uses it.

It's quite easy to write a wrapper class which will call NetRexxC and
JDT one after another in a nice, prepacked jar file... just to lessen
the hilarious pain one has installing a working NetRexxC environment on
MacOS, Windows, Linux and Solaris while not being an expert on all of
these platforms. Go ahead and try it once... ;-)

Patric

David Requena schrieb am 15.03.2010 14:53:

>
> The fact remains that as far as the NetRexx language processor does not
> produce
> byte code directly, some java compiler will be needed. Be it the one
> from the
> standard jdk's or some other exotic one.
>
> If that is such a big issue, why not spend the effort on the direct
> bytecode generation aspect?
>
> ---
> Saludos / Kind regards.
> David Requena
>
>
> El 15/03/2010 11:15, René Jansen escribió:
>> Patric,
>>
>> thanks for this valuable pointer. OTOH, NetRexx has already impressive
>> bytecode generation features in the interpreter part; as always, it is
>> about carefully introducing or leaving out dependencies.
>>
>> I had a look at the Eclipse JDT - it requires one to speficy a Java
>> rt.jar - it would solve the JRE problem but not all the location
>> problems. Next thing I am going to look at is the source of javac -
>> the launcher, not the Java compiler part, and see what that has to
>> offer in terms of inspiration.
>>
>> best regards,
>>
>> René.
>>
>> On Mon, Mar 15, 2010 at 4:05 AM, Tom Maynard<[hidden email]>  wrote:
>>  
>>> Patric Bechtel wrote:
>>>
>>> - - using the JDT compiler instead of relying upon the javac compiler
>>> (and
>>> on the user installing a jdk instead of the mostly preinstalled jre).
>>> The JDT compiler is very compact and would enable a "instant on"
>>> experience for the user.
>>>
>>>
>>>
>>> Another option to consider: Janino.  From the webpage:
>>>
>>> Janino is a compiler that reads a JavaTM expression, block, class body,
>>> source file or a set of source files, and generates JavaTM bytecode
>>> that is
>>> loaded and executed directly. Janino is not intended to be a development
>>> tool, but an embedded compiler for run-time compilation purposes, e.g.
>>> expression evaluators or "server pages" engines like JSP.
>>>
>>> JANINO is integrated with Apache Commons JCI ("Java Compiler
>>> Interface") and
>>> JBoss Rules / Drools.
>>>
>>> JANINO can also be used for static code analysis or code manipulation.
>>>
>>> The webpage is http://docs.codehaus.org/display/JANINO/Home.
>>> Otherwise I
>>> have no knowledge or experience with the application.  I'm just
>>> keeping the
>>> group's options open (I hope).
>>>
>>> Tom.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: GnuPT 2.5.2

iEYEARECAAYFAkueQYwACgkQfGgGu8y7ypB8egCg2/Ub9d2Dq2uzWm0BFaaVNFFd
iOUAnA2TvGDA1S7FLnEM9Iaxu7dWj/au
=zFxE
-----END PGP SIGNATURE-----
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Michael Dag]

I'd rather focus on showing what you can do with NetRexx in an easy way,

With some good samples, like (just a few ideas in random order...)
 
- Hello World (simple I/O + scripting)
- Hello File (how to do do simple file IO),
- Hello XML (how to handle XML file parsing + perhaps using SAX from
NetRexx?),
- Hello Service (how to use a NetRexx class on a webserver and embed in an
HTML page with input/output?)
- Hello Java (how in general to use NetRexx with java tools/libraries)
- Hello GUI (how to do simple GUI stuff with NetRexx)
- Hello plug-in (how to write an Eclipse plugin with NetRexx)  

If the "passer-by" is tempted enough by the samples and the simplicity
provided
by the Language he will want to make this work on his system...

I have seen to many people, not looking at their screen at all and just
claiming "it doesn't work"
when all the screen said was "Bad command or file name" ... ???-(((  

Michael

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Patric Bechtel
Sent: maandag 15 maart 2010 14:34
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] NetRexx installation revisited

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

my tips here wasn't meant just for "passers-by", whatever that is.

Java *can* be a pain in the butt when it comes to classpath hell. To ease
that pain or, in terms of NetRexx newbies, I think it would be nice to have
a smooth language experience. Especially, if NetRexx is your first contact
to Java; in that case, every bad experience with Java will be a bad
experience of "NetRexx", the newbies cannot tell the culprit.

My fear is, that, if you use another language for the first time, you get
"wrapped" into an IDE, so most of these issues are solved there.
NetRexx doesn't have an IDE (I wouldn't call jEdit, which is my favourite
editor for almost a decade already, an IDE), and that will be the case for
quite some time.

Anyway, I don't like IDE's, and the elegance of having a small download and
an instant "see, it works" experience has much of an exciting moment for a
newbie. Especially when putting your first program to another machine, maybe
with on OS you're not an expert, and it just works there, too.

What I would like to see in near future is something like the scala or
groovy interactive shell, which make testing and playing so much easier,
even for profs like me.

just my 0.02?...

Patric

David Requena schrieb am 15.03.2010 13:30:
> In the discussion bellow the term classpath is used in 2 distinct
meanings:

>
> "CLASSPATH" (in upper-case) is meant as an environment variable
> hinting the jre which actual logical "classpath" (in lower-case) to
> use while trying to load classes.
>
>> - the people who know Java and their platform;
>> - the people coming from other Rexxen trying out the promise of the
>> world of the Java VM and its standardized class libraries;
>> - passers-by maybe entering the world of programming or maybe
>> disillusioned by the runtime performance of jruby and jpython (we
>> have to work on that ;-))
>>  
>
> I only see 2 groups.
>
> "Passers-by entering the world of programming" not willing to invest
> half an our reading some set-up instructions are not going to program
> anything of any interest, in any language... ever! These should not be
> our target audience.
>
>> As often is the case, the requirements and needs of these are different.

People coming from Java (like myself, I did some Java before discovering
NetRexx through Ed Tomlinson's Pipes for NetRexx package, but with earlier
Rexx experience on MVS, OS/2 and NT) generally have no issues, drop the jar
somewhere, edit the classpath and go. After some reflection and re-reading
of past messages I now do agree that the first group does not need to be
catered for at all, but the others do. The second group can be catered for
with correct and elaborate instructions. My worries here concern the last
mentioned group, the passers-by. I am passing by a lot of languages and
compilers, and the number one put-off to try and install some compiler is a
long list of instructions - there is even some equation in which the lenght
of the instruction lists is equal to the failure rate.
>>  
>
> Yes, programming is not easy. I agree it is not a thing for everyone.
> Are we really trying to build a pedagogical programming language to
> get the 5% people who actually become programmers at some point move
> to some other "real language" latter?
>
>> Thus my proposal would be to have only a modest set of instructions added
to the distribution archive; split up in separate pdf files for every major
platform (Wintel, Linux-x86, Linux-Z, Aix, MacOSX). The 'elaborate sets'
should be in the wiki on www.netrexx.org and linked to from these documents
- Chip's excellent instruction/verification text should go in there.
>>  
>
> I agree Chip made an excellent job. Some issues remain IIRC as there
> was some hard-coded path in his batch file though.
>
>> The passers-by need to be catered for, if only because in the literature
describing the history of Rexx, parallells with BASIC and Logo are drawn. We
can say what we want about BASIC, the line numbered version, but it has
attained its goal of enabling novices to program, and Logo is, I heard, even
teachable to 5-years old (although I suspect that would be the crawling
turtle part, not the recursive list hierarchy transversal part).

>>  
>
> I learnt how to program in a CBM 64 using BASIC indeed. Many of my
> friends also tried at the time. Most of them never got past:
>
> 10 PRINT"MY BROTHER IS AN AS*H*LE"
> 20 GOTO10
>
> Some even reached
>
> 10 X$=0
> 20 X$=X$+1:PRINTX$;"MY BROTHER IS AN AS*H*LE"
> 30 GOTO20
>
> The rest spent a lot of time studying memory maps, learning how to
> call kernal routines, etc. Then moved to 6502 assembler as soon as we
> could. Here "the rest"
> & "we" includes just me, what's the point in enabling my aunt Rosario
> writing a hello-world program at all?
>
> The fact is that programming requires some learning effort. That's
> true even when trying to program your VCR or washing machine.
>
>> Different OS platforms have different strategies for the placement of the

standard platform JVM (if any), (several) different JVM's can be installed
on a platform, and some users may even switch JVMs during the development
cycle, for example for the purpose of regression testing. The effects of the
combination of, for example, a heterogeneous set of shared libraries and
java archives can range from unnoticed to bewildering, to catastrophic.
>>  
>
> I guess people with such a "complex" jvm set-up are coming from your
> first group:
> the one not experiencing any trouble setting the classpath right :-)
>
>> I think the principles on which we base the solutions for the encountered
problems, must be to use environmental platform clues as much as possible,
and the NetRexx translator itself must be very sparingly (and always
relative to the environmental hint) guess where the correct libraries are.
Even on MacOSX, where the Java locations were fixed for years, I am
encountering two movements: the Apple team thinking of alternative packaging
structure, moving eventually to mainstream *nix conventions, and in the
meantime offering a program to locate the JAVA_HOME; and the open source Sun
JDK7 releases being used as an alternative for people experimenting with
InvokeDynamic, tail recursion and other great things to come to the JVM.
>>
>> A subject of discussion is the use of the standard 'blessed' extension
directories: they were not always there, they seem to multiply on some
platforms, they might work differently among JVM vendors, and I see a high
incidence of trouble with people using them. I do not have any problem with
a user preference for their use, only I am loathe to advice to use them in
the standard install document when this does not turn out to be a totally
dependable mechanism. As a side thought - it might hinder understanding of
the classpath model, which leads to trouble with the first application that
is not in the default package.

>>  
>
> I think is time for all of us to forget about both CLASSPATH and
> extensions directories once for all.
> These just add complexity to an actually simple subject:
>
> When you compile something in any language, you tell your compiler
> where to find needed libraries and or components. In java (and in
> NetRexx) this is done by specifying a classpath at the command line.
> In fact it's even easier than in most other compiled languages, where
> you have to cater for declarations and implementations or binary
> objects separately. Yeah, that wouldn't be the case when programming
> your run of the mill hello-world program...
>
>> - a package-less 'nrc' class in the jar that has a main that calls
>> the translator for a compile, and a .manifest file that declares that
>> main, enabling users to start a compile with 'java -jar NetRexxC.jar
>> SourceFile[.nrx]';
>> - platform dependent hints in the translator, relative to a JAVA_HOME
>> environmental setting. For the open source releases we can have minor
>> versions that address changes on the platforms;
>>  
>
> Agree that could save some typing.
>
>> - a extra System.exec('java') when the Java compiler class cannot be
>> found (funny enough a successful Java SDK enables the javac, which is
>> a very thin native invoker executable for a Java program, to find its
>> compiler class)
>>  
>
> Hmmm... not sure I follow you here... Wouldn't a *clear* jdk
> requirement save most of the trouble people are experiencing?
>
>> One snag here is that fetching environment variables has been deprected

in Java for a number of years (not every platform - phones -  have them) but
since that seems to be reversed, and other language processors use them, I
gather we are safe here for the future.
>>  
>
> I don't think environment variables, as such, are deprecated at all.
> This is a system
> specific thing having nothing to do with java itself . It's just
> CLASSPATH which has been deprecated since at least java 2 version 1.2
>
>> For the moment, I would like to avoid a native or Java-installer approach
that needs all this knowledge of platforms and possible combinations of JVM
releases on machines out there. But I would certainly not oppose someone to
pick this up and support this.

>>  
>
> Agree this would involve platform specific code but the truth is that
> NetRexx today is being distributed with platform specific non-working
> scripts!
>
> Here is my proposal:
>
> - Distribute NetRexx with working scripts just dependent on a couple
> environment
>   variables. Say NRX_HOME and NRX_JDK.
> - Bundle a simple NrxInstall package-less class in the main
> NetRexxC.jar
> - Instruct the user to type "java -cp NetRexxC.jar NrxInstall
>
> This would just ask 2 questions to the user:
>
> - ¿Where is your jdk installed?
>
>   A check is done for an actual jdk install there. If not present, we
> ask again.
>   Some intelligence could be built in as to a tries to automatically find

an

>   installed jdk.
>
> - ¿Where do you want to install NetRexx?
>
>   This defaults to where NetRexxC.jar is located for this execution of
> NrxInstall. We
>   already have this information from the command line. If user changes
> this, then we
>   copy NetRexxC.jar to desired location.
>
> Finally NrxInstall intructs the user to put the second directory in
> his PATH if he wants to save some typing and what command to type if
> he does not.
>
> That's it. Rerun this every time you mess with your java environment.
>
> Honestly, this takes so much more to explain than to do. I would
> already have done it if I had had the time. Just too many balls
> airborne at once :-)
>
>
>> A separate 'Building applications for NetRexx' document, should
>> contain chapters on package and directory structure, and touch
>> subjects like the use of 'make', 'ant' and 'maven', class-in-source
>> or not, generating Javadoc, how to handle dependencies, etc. On a
>> side thought,
>
> Yeah, a Developers Guide would be great!
>
>> I wonder if our planned cpan-like repository could be a maven repository.

The 'Building' document should explain about how to structure for NetRexx
web apps using J2EE packaging conventions for JBoss, Glassfish and
WebSphere. Obviously I would welcome volunteers to start building this
information.
>>  
>
> Hmm... not sure. Developing suitable Netbeans and Eclipse plugins for
> NetRexx would cover 95% of this. And it would help raise mainstream
> NetRexx awareness sooo muuch more!
>
>> Please let me know what you think - I already know that we would like the
open source release to happen soon - but we can do so much as a community
already before that happens.
>
> Fully agree
>
>> I will try to have the wiki up somewhere this weekend. It will be a
JSPWiki, not the slickest around, but it enables us to extend it and brand
the site NetRexx - powered. It will probably start out with three projects
on it - installation, building and IDE - but even the table of contents will
be user-editable.

>>  
>
> That is great news indeed.
>
>
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: GnuPT 2.5.2

iEYEARECAAYFAkueNy4ACgkQfGgGu8y7ypAdEgCfeUKi/AOlbOmRJDecJ2wic6/7
bJoAoLv5UaOcIKGTX1d6/sHOrLxlFVDW
=lMvn
-----END PGP SIGNATURE-----
_______________________________________________
Ibm-netrexx mailing list
[hidden email]


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Patric Bechtel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mike,

thanks a lot... that comes out more or less like the tips I gave: get
the URLs of the jars and call the JDT compiler...

Just without WebStart, because it only works if you have a GUI, which we
don't have yet. An included jEdit (2.x?) maybe?

Patric

Measel, Mike schrieb am 15.03.2010 15:15:

> Here is (from 2005!)  Using Java compiler in your Web Start application
> http://weblogs.java.net/blog/2005/05/27/using-java-compiler-your-web-start-application
>
> We have been running java applications with "Web Start" for some years now. It makes keeping everything tidy and always in sync even as jvms and jdks come and go.  
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of David Requena
> Sent: Monday, March 15, 2010 8:54 AM
> To: IBM Netrexx
> Subject: Re: [Ibm-netrexx] NetRexx installation revisited
>
>
> The fact remains that as far as the NetRexx language processor does not
> produce
> byte code directly, some java compiler will be needed. Be it the one
> from the
> standard jdk's or some other exotic one.
>
> If that is such a big issue, why not spend the effort on the direct
> bytecode generation aspect?
>
> ---
> Saludos / Kind regards.
> David Requena
>
>
> El 15/03/2010 11:15, René Jansen escribió:
>> Patric,
>>
>> thanks for this valuable pointer. OTOH, NetRexx has already impressive
>> bytecode generation features in the interpreter part; as always, it is
>> about carefully introducing or leaving out dependencies.
>>
>> I had a look at the Eclipse JDT - it requires one to speficy a Java
>> rt.jar - it would solve the JRE problem but not all the location
>> problems. Next thing I am going to look at is the source of javac -
>> the launcher, not the Java compiler part, and see what that has to
>> offer in terms of inspiration.
>>
>> best regards,
>>
>> René.
>>
>> On Mon, Mar 15, 2010 at 4:05 AM, Tom Maynard<[hidden email]>  wrote:
>>    
>>> Patric Bechtel wrote:
>>>
>>> - - using the JDT compiler instead of relying upon the javac compiler (and
>>> on the user installing a jdk instead of the mostly preinstalled jre).
>>> The JDT compiler is very compact and would enable a "instant on"
>>> experience for the user.
>>>
>>>
>>>
>>> Another option to consider: Janino.  From the webpage:
>>>
>>> Janino is a compiler that reads a JavaTM expression, block, class body,
>>> source file or a set of source files, and generates JavaTM bytecode that is
>>> loaded and executed directly. Janino is not intended to be a development
>>> tool, but an embedded compiler for run-time compilation purposes, e.g.
>>> expression evaluators or "server pages" engines like JSP.
>>>
>>> JANINO is integrated with Apache Commons JCI ("Java Compiler Interface") and
>>> JBoss Rules / Drools.
>>>
>>> JANINO can also be used for static code analysis or code manipulation.
>>>
>>> The webpage is http://docs.codehaus.org/display/JANINO/Home.  Otherwise I
>>> have no knowledge or experience with the application.  I'm just keeping the
>>> group's options open (I hope).
>>>
>>> Tom.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: GnuPT 2.5.2

iEYEARECAAYFAkueRnAACgkQfGgGu8y7ypCkswCeO6CnPLvFzZmfDjGPQ6UjTUy2
h8AAn1oxtsa8igTeL9yOo/7uZ39ayZ51
=LuX0
-----END PGP SIGNATURE-----
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

El 15/03/2010 15:17, Patric Bechtel escribió:
> that won't work until NetRexx is open sourced, which is some unknown
> time to be. The compiler from the eclipse project is not really
> experimental btw, everyone using the eclipse IDE uses it.
>    

I never said 'experimental', but 'exotic' :-)

> It's quite easy to write a wrapper class which will call NetRexxC and
> JDT one after another in a nice, prepacked jar file...

Don't know about JTD itself but Eclipse as a whole does not run on every
platform
java does.

>   just to lessen
> the hilarious pain one has installing a working NetRexxC environment on
> MacOS, Windows, Linux and Solaris while not being an expert on all of
> these platforms. Go ahead and try it once...;-)
>
>    

I would say it's easier to setup on any platform just by

- reading some updated lightweight doc (mainly, forget about CLASSPATH
and ext directories and mention a jdk as a REQUIREMENT).
- setting a couple environment vars (tools.jar path + NetRexxC.jar path)
- using updated scripts which use these vars instead of hard-coded paths
or relying on the system PATH.

Bundling a whole java compiler + supporting files seems way as an
overkill to me given that:

The point here is that all of this will just allow a newcomer to compile
the typical hello-world. Nothing else.
The moment an 'import' instruction is used, some understanding of the
classpath model will be needed.

Yeah.. not much can be accomplished without imports...


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

Michael,

I cannot agree more with you

"Do not give them fish; teach them how to fish" :-)

---
Saludos / Kind regards.
David Requena


El 15/03/2010 15:22, Michael Dag escribió:

> I'd rather focus on showing what you can do with NetRexx in an easy way,
>
> With some good samples, like (just a few ideas in random order...)
>
> - Hello World (simple I/O + scripting)
> - Hello File (how to do do simple file IO),
> - Hello XML (how to handle XML file parsing + perhaps using SAX from
> NetRexx?),
> - Hello Service (how to use a NetRexx class on a webserver and embed in an
> HTML page with input/output?)
> - Hello Java (how in general to use NetRexx with java tools/libraries)
> - Hello GUI (how to do simple GUI stuff with NetRexx)
> - Hello plug-in (how to write an Eclipse plugin with NetRexx)
>
> If the "passer-by" is tempted enough by the samples and the simplicity
> provided
> by the Language he will want to make this work on his system...
>
> I have seen to many people, not looking at their screen at all and just
> claiming "it doesn't work"
> when all the screen said was "Bad command or file name" ... ???-(((
>
> Michael
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Patric Bechtel
> Sent: maandag 15 maart 2010 14:34
> To: IBM Netrexx
> Subject: Re: [Ibm-netrexx] NetRexx installation revisited
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> my tips here wasn't meant just for "passers-by", whatever that is.
>
> Java *can* be a pain in the butt when it comes to classpath hell. To ease
> that pain or, in terms of NetRexx newbies, I think it would be nice to have
> a smooth language experience. Especially, if NetRexx is your first contact
> to Java; in that case, every bad experience with Java will be a bad
> experience of "NetRexx", the newbies cannot tell the culprit.
>
> My fear is, that, if you use another language for the first time, you get
> "wrapped" into an IDE, so most of these issues are solved there.
> NetRexx doesn't have an IDE (I wouldn't call jEdit, which is my favourite
> editor for almost a decade already, an IDE), and that will be the case for
> quite some time.
>
> Anyway, I don't like IDE's, and the elegance of having a small download and
> an instant "see, it works" experience has much of an exciting moment for a
> newbie. Especially when putting your first program to another machine, maybe
> with on OS you're not an expert, and it just works there, too.
>
> What I would like to see in near future is something like the scala or
> groovy interactive shell, which make testing and playing so much easier,
> even for profs like me.
>
> just my 0.02?...
>
> Patric
>
> David Requena schrieb am 15.03.2010 13:30:
>    
>> In the discussion bellow the term classpath is used in 2 distinct
>>      
> meanings:
>    
>> "CLASSPATH" (in upper-case) is meant as an environment variable
>> hinting the jre which actual logical "classpath" (in lower-case) to
>> use while trying to load classes.
>>
>>      
>>> - the people who know Java and their platform;
>>> - the people coming from other Rexxen trying out the promise of the
>>> world of the Java VM and its standardized class libraries;
>>> - passers-by maybe entering the world of programming or maybe
>>> disillusioned by the runtime performance of jruby and jpython (we
>>> have to work on that ;-))
>>>
>>>        
>> I only see 2 groups.
>>
>> "Passers-by entering the world of programming" not willing to invest
>> half an our reading some set-up instructions are not going to program
>> anything of any interest, in any language... ever! These should not be
>> our target audience.
>>
>>      
>>> As often is the case, the requirements and needs of these are different.
>>>        
> People coming from Java (like myself, I did some Java before discovering
> NetRexx through Ed Tomlinson's Pipes for NetRexx package, but with earlier
> Rexx experience on MVS, OS/2 and NT) generally have no issues, drop the jar
> somewhere, edit the classpath and go. After some reflection and re-reading
> of past messages I now do agree that the first group does not need to be
> catered for at all, but the others do. The second group can be catered for
> with correct and elaborate instructions. My worries here concern the last
> mentioned group, the passers-by. I am passing by a lot of languages and
> compilers, and the number one put-off to try and install some compiler is a
> long list of instructions - there is even some equation in which the lenght
> of the instruction lists is equal to the failure rate.
>    
>>>
>>>        
>> Yes, programming is not easy. I agree it is not a thing for everyone.
>> Are we really trying to build a pedagogical programming language to
>> get the 5% people who actually become programmers at some point move
>> to some other "real language" latter?
>>
>>      
>>> Thus my proposal would be to have only a modest set of instructions added
>>>        
> to the distribution archive; split up in separate pdf files for every major
> platform (Wintel, Linux-x86, Linux-Z, Aix, MacOSX). The 'elaborate sets'
> should be in the wiki on www.netrexx.org and linked to from these documents
> - Chip's excellent instruction/verification text should go in there.
>    
>>>
>>>        
>> I agree Chip made an excellent job. Some issues remain IIRC as there
>> was some hard-coded path in his batch file though.
>>
>>      
>>> The passers-by need to be catered for, if only because in the literature
>>>        
> describing the history of Rexx, parallells with BASIC and Logo are drawn. We
> can say what we want about BASIC, the line numbered version, but it has
> attained its goal of enabling novices to program, and Logo is, I heard, even
> teachable to 5-years old (although I suspect that would be the crawling
> turtle part, not the recursive list hierarchy transversal part).
>    
>>>
>>>        
>> I learnt how to program in a CBM 64 using BASIC indeed. Many of my
>> friends also tried at the time. Most of them never got past:
>>
>> 10 PRINT"MY BROTHER IS AN AS*H*LE"
>> 20 GOTO10
>>
>> Some even reached
>>
>> 10 X$=0
>> 20 X$=X$+1:PRINTX$;"MY BROTHER IS AN AS*H*LE"
>> 30 GOTO20
>>
>> The rest spent a lot of time studying memory maps, learning how to
>> call kernal routines, etc. Then moved to 6502 assembler as soon as we
>> could. Here "the rest"
>> &  "we" includes just me, what's the point in enabling my aunt Rosario
>> writing a hello-world program at all?
>>
>> The fact is that programming requires some learning effort. That's
>> true even when trying to program your VCR or washing machine.
>>
>>      
>>> Different OS platforms have different strategies for the placement of the
>>>        
> standard platform JVM (if any), (several) different JVM's can be installed
> on a platform, and some users may even switch JVMs during the development
> cycle, for example for the purpose of regression testing. The effects of the
> combination of, for example, a heterogeneous set of shared libraries and
> java archives can range from unnoticed to bewildering, to catastrophic.
>    
>>>
>>>        
>> I guess people with such a "complex" jvm set-up are coming from your
>> first group:
>> the one not experiencing any trouble setting the classpath right :-)
>>
>>      
>>> I think the principles on which we base the solutions for the encountered
>>>        
> problems, must be to use environmental platform clues as much as possible,
> and the NetRexx translator itself must be very sparingly (and always
> relative to the environmental hint) guess where the correct libraries are.
> Even on MacOSX, where the Java locations were fixed for years, I am
> encountering two movements: the Apple team thinking of alternative packaging
> structure, moving eventually to mainstream *nix conventions, and in the
> meantime offering a program to locate the JAVA_HOME; and the open source Sun
> JDK7 releases being used as an alternative for people experimenting with
> InvokeDynamic, tail recursion and other great things to come to the JVM.
>    
>>> A subject of discussion is the use of the standard 'blessed' extension
>>>        
> directories: they were not always there, they seem to multiply on some
> platforms, they might work differently among JVM vendors, and I see a high
> incidence of trouble with people using them. I do not have any problem with
> a user preference for their use, only I am loathe to advice to use them in
> the standard install document when this does not turn out to be a totally
> dependable mechanism. As a side thought - it might hinder understanding of
> the classpath model, which leads to trouble with the first application that
> is not in the default package.
>    
>>>
>>>        
>> I think is time for all of us to forget about both CLASSPATH and
>> extensions directories once for all.
>> These just add complexity to an actually simple subject:
>>
>> When you compile something in any language, you tell your compiler
>> where to find needed libraries and or components. In java (and in
>> NetRexx) this is done by specifying a classpath at the command line.
>> In fact it's even easier than in most other compiled languages, where
>> you have to cater for declarations and implementations or binary
>> objects separately. Yeah, that wouldn't be the case when programming
>> your run of the mill hello-world program...
>>
>>      
>>> - a package-less 'nrc' class in the jar that has a main that calls
>>> the translator for a compile, and a .manifest file that declares that
>>> main, enabling users to start a compile with 'java -jar NetRexxC.jar
>>> SourceFile[.nrx]';
>>> - platform dependent hints in the translator, relative to a JAVA_HOME
>>> environmental setting. For the open source releases we can have minor
>>> versions that address changes on the platforms;
>>>
>>>        
>> Agree that could save some typing.
>>
>>      
>>> - a extra System.exec('java') when the Java compiler class cannot be
>>> found (funny enough a successful Java SDK enables the javac, which is
>>> a very thin native invoker executable for a Java program, to find its
>>> compiler class)
>>>
>>>        
>> Hmmm... not sure I follow you here... Wouldn't a *clear* jdk
>> requirement save most of the trouble people are experiencing?
>>
>>      
>>> One snag here is that fetching environment variables has been deprected
>>>        
> in Java for a number of years (not every platform - phones -  have them) but
> since that seems to be reversed, and other language processors use them, I
> gather we are safe here for the future.
>    
>>>
>>>        
>> I don't think environment variables, as such, are deprecated at all.
>> This is a system
>> specific thing having nothing to do with java itself . It's just
>> CLASSPATH which has been deprecated since at least java 2 version 1.2
>>
>>      
>>> For the moment, I would like to avoid a native or Java-installer approach
>>>        
> that needs all this knowledge of platforms and possible combinations of JVM
> releases on machines out there. But I would certainly not oppose someone to
> pick this up and support this.
>    
>>>
>>>        
>> Agree this would involve platform specific code but the truth is that
>> NetRexx today is being distributed with platform specific non-working
>> scripts!
>>
>> Here is my proposal:
>>
>> - Distribute NetRexx with working scripts just dependent on a couple
>> environment
>>    variables. Say NRX_HOME and NRX_JDK.
>> - Bundle a simple NrxInstall package-less class in the main
>> NetRexxC.jar
>> - Instruct the user to type "java -cp NetRexxC.jar NrxInstall
>>
>> This would just ask 2 questions to the user:
>>
>> - ¿Where is your jdk installed?
>>
>>    A check is done for an actual jdk install there. If not present, we
>> ask again.
>>    Some intelligence could be built in as to a tries to automatically find
>>      
> an
>    
>>    installed jdk.
>>
>> - ¿Where do you want to install NetRexx?
>>
>>    This defaults to where NetRexxC.jar is located for this execution of
>> NrxInstall. We
>>    already have this information from the command line. If user changes
>> this, then we
>>    copy NetRexxC.jar to desired location.
>>
>> Finally NrxInstall intructs the user to put the second directory in
>> his PATH if he wants to save some typing and what command to type if
>> he does not.
>>
>> That's it. Rerun this every time you mess with your java environment.
>>
>> Honestly, this takes so much more to explain than to do. I would
>> already have done it if I had had the time. Just too many balls
>> airborne at once :-)
>>
>>
>>      
>>> A separate 'Building applications for NetRexx' document, should
>>> contain chapters on package and directory structure, and touch
>>> subjects like the use of 'make', 'ant' and 'maven', class-in-source
>>> or not, generating Javadoc, how to handle dependencies, etc. On a
>>> side thought,
>>>        
>> Yeah, a Developers Guide would be great!
>>
>>      
>>> I wonder if our planned cpan-like repository could be a maven repository.
>>>        
> The 'Building' document should explain about how to structure for NetRexx
> web apps using J2EE packaging conventions for JBoss, Glassfish and
> WebSphere. Obviously I would welcome volunteers to start building this
> information.
>    
>>>
>>>        
>> Hmm... not sure. Developing suitable Netbeans and Eclipse plugins for
>> NetRexx would cover 95% of this. And it would help raise mainstream
>> NetRexx awareness sooo muuch more!
>>
>>      
>>> Please let me know what you think - I already know that we would like the
>>>        
> open source release to happen soon - but we can do so much as a community
> already before that happens.
>    
>> Fully agree
>>
>>      
>>> I will try to have the wiki up somewhere this weekend. It will be a
>>>        
> JSPWiki, not the slickest around, but it enables us to extend it and brand
> the site NetRexx - powered. It will probably start out with three projects
> on it - installation, building and IDE - but even the table of contents will
> be user-editable.
>    
>>>
>>>        
>> That is great news indeed.
>>
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>      
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: GnuPT 2.5.2
>
> iEYEARECAAYFAkueNy4ACgkQfGgGu8y7ypAdEgCfeUKi/AOlbOmRJDecJ2wic6/7
> bJoAoLv5UaOcIKGTX1d6/sHOrLxlFVDW
> =lMvn
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>    

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

Hi Patric & all,
  may I *again* suggest to use JEdit as the first NetRexx IDE to be
implemented.

Reasons are:

   -- Kermit Kiser's wonderful NetRexxScript already is an official
Jedit Plugin
   -- I already tried JEdit for classic Rexx and PL/I and COBOL -- works
   -- David Requenas'  NetRexxDE will be a JEdit plugin as well very soon.
   -- and when I will have released my Rey Compiler, I will, most probably,
build a JEdit plugin as well --- based on the work of Kermit & David.

Later on, *after the common NetRexx open source* release task, we all could
concentrate on Eclipse or whatever, when the demand is there...

Kind regards,
Tom.
=====================================================
Patric Bechtel schrieb:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Mike,
>
> thanks a lot... that comes out more or less like the tips I gave: get
> the URLs of the jars and call the JDT compiler...
>
> Just without WebStart, because it only works if you have a GUI, which we
> don't have yet. An included jEdit (2.x?) maybe?
>
> Patric
>
> Measel, Mike schrieb am 15.03.2010 15:15:
>  
>> Here is (from 2005!)  Using Java compiler in your Web Start application
>> http://weblogs.java.net/blog/2005/05/27/using-java-compiler-your-web-start-application
>>
>> We have been running java applications with "Web Start" for some years now. It makes keeping everything tidy and always in sync even as jvms and jdks come and go.  
>>
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On Behalf Of David Requena
>> Sent: Monday, March 15, 2010 8:54 AM
>> To: IBM Netrexx
>> Subject: Re: [Ibm-netrexx] NetRexx installation revisited
>>
>>
>> The fact remains that as far as the NetRexx language processor does not
>> produce
>> byte code directly, some java compiler will be needed. Be it the one
>> from the
>> standard jdk's or some other exotic one.
>>
>> If that is such a big issue, why not spend the effort on the direct
>> bytecode generation aspect?
>>
>> ---
>> Saludos / Kind regards.
>> David Requena
>>
>>
>> El 15/03/2010 11:15, René Jansen escribió:
>>    
>>> Patric,
>>>
>>> thanks for this valuable pointer. OTOH, NetRexx has already impressive
>>> bytecode generation features in the interpreter part; as always, it is
>>> about carefully introducing or leaving out dependencies.
>>>
>>> I had a look at the Eclipse JDT - it requires one to speficy a Java
>>> rt.jar - it would solve the JRE problem but not all the location
>>> problems. Next thing I am going to look at is the source of javac -
>>> the launcher, not the Java compiler part, and see what that has to
>>> offer in terms of inspiration.
>>>
>>> best regards,
>>>
>>> René.
>>>
>>> On Mon, Mar 15, 2010 at 4:05 AM, Tom Maynard<[hidden email]>  wrote:
>>>    
>>>      
>>>> Patric Bechtel wrote:
>>>>
>>>> - - using the JDT compiler instead of relying upon the javac compiler (and
>>>> on the user installing a jdk instead of the mostly preinstalled jre).
>>>> The JDT compiler is very compact and would enable a "instant on"
>>>> experience for the user.
>>>>
>>>>
>>>>
>>>> Another option to consider: Janino.  From the webpage:
>>>>
>>>> Janino is a compiler that reads a JavaTM expression, block, class body,
>>>> source file or a set of source files, and generates JavaTM bytecode that is
>>>> loaded and executed directly. Janino is not intended to be a development
>>>> tool, but an embedded compiler for run-time compilation purposes, e.g.
>>>> expression evaluators or "server pages" engines like JSP.
>>>>
>>>> JANINO is integrated with Apache Commons JCI ("Java Compiler Interface") and
>>>> JBoss Rules / Drools.
>>>>
>>>> JANINO can also be used for static code analysis or code manipulation.
>>>>
>>>> The webpage is http://docs.codehaus.org/display/JANINO/Home.  Otherwise I
>>>> have no knowledge or experience with the application.  I'm just keeping the
>>>> group's options open (I hope).
>>>>
>>>> Tom.
>>>>        
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: GnuPT 2.5.2
>
> iEYEARECAAYFAkueRnAACgkQfGgGu8y7ypCkswCeO6CnPLvFzZmfDjGPQ6UjTUy2
> h8AAn1oxtsa8igTeL9yOo/7uZ39ayZ51
> =LuX0
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>
>  

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

David, I'm already spending time to directly produce byte-code as the
next step
of my Rey Compiler  ...
Tom (Thomas Schneider)
==========================================================
David Requena schrieb:

>
> The fact remains that as far as the NetRexx language processor does
> not produce
> byte code directly, some java compiler will be needed. Be it the one
> from the
> standard jdk's or some other exotic one.
>
> If that is such a big issue, why not spend the effort on the direct
> bytecode generation aspect?
>
> ---
> Saludos / Kind regards.
> David Requena
>
>
> El 15/03/2010 11:15, René Jansen escribió:
>> Patric,
>>
>> thanks for this valuable pointer. OTOH, NetRexx has already impressive
>> bytecode generation features in the interpreter part; as always, it is
>> about carefully introducing or leaving out dependencies.
>>
>> I had a look at the Eclipse JDT - it requires one to speficy a Java
>> rt.jar - it would solve the JRE problem but not all the location
>> problems. Next thing I am going to look at is the source of javac -
>> the launcher, not the Java compiler part, and see what that has to
>> offer in terms of inspiration.
>>
>> best regards,
>>
>> René.
>>
>> On Mon, Mar 15, 2010 at 4:05 AM, Tom Maynard<[hidden email]>  wrote:
>>  
>>> Patric Bechtel wrote:
>>>
>>> - - using the JDT compiler instead of relying upon the javac
>>> compiler (and
>>> on the user installing a jdk instead of the mostly preinstalled jre).
>>> The JDT compiler is very compact and would enable a "instant on"
>>> experience for the user.
>>>
>>>
>>>
>>> Another option to consider: Janino.  From the webpage:
>>>
>>> Janino is a compiler that reads a JavaTM expression, block, class body,
>>> source file or a set of source files, and generates JavaTM bytecode
>>> that is
>>> loaded and executed directly. Janino is not intended to be a
>>> development
>>> tool, but an embedded compiler for run-time compilation purposes, e.g.
>>> expression evaluators or "server pages" engines like JSP.
>>>
>>> JANINO is integrated with Apache Commons JCI ("Java Compiler
>>> Interface") and
>>> JBoss Rules / Drools.
>>>
>>> JANINO can also be used for static code analysis or code manipulation.
>>>
>>> The webpage is http://docs.codehaus.org/display/JANINO/Home.  
>>> Otherwise I
>>> have no knowledge or experience with the application.  I'm just
>>> keeping the
>>> group's options open (I hope).
>>>
>>> Tom.
>>>
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>>
>>>
>>>
>>>      
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>    
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Kermit Kiser]

@ Patric ;

I am a little puzzled. I looked at the Scala and Groovy languages and shells and I am not impressed.

They look much more difficult to use than NetRexx. Especially with the jEdit NetRexx plugins NetRexxDE and NetRexxScript. Granted, I already know how to use the jEdit editor environment so I am not the best judge of how difficult that is to setup and learn to use. But it is a fairly standard GUI type interface that should be usable with minimal directions to anyone with even a little modern computer experience.

And can't you run NetRexx in interpreter mode for an interactive shell?

So why do you want something like the Scala/Groovy interfaces which don't seem nearly as easy to use as NetRexxScript where you can just type some NetRexx code and click a button to run it? What am I missing?

-- Kermit

Patric Bechtel wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

my tips here wasn't meant just for "passers-by", whatever that is.

Java *can* be a pain in the butt when it comes to classpath hell. To
ease that pain or, in terms of NetRexx newbies, I think it would be nice
to have a smooth language experience. Especially, if NetRexx is your
first contact to Java; in that case, every bad experience with Java will
be a bad experience of "NetRexx", the newbies cannot tell the culprit.

My fear is, that, if you use another language for the first time, you
get "wrapped" into an IDE, so most of these issues are solved there.
NetRexx doesn't have an IDE (I wouldn't call jEdit, which is my
favourite editor for almost a decade already, an IDE), and that will be
the case for quite some time.

Anyway, I don't like IDE's, and the elegance of having a small download
and an instant "see, it works" experience has much of an exciting moment
for a newbie. Especially when putting your first program to another
machine, maybe with on OS you're not an expert, and it just works there,
too.

What I would like to see in near future is something like the scala or
groovy interactive shell, which make testing and playing so much easier,
even for profs like me.

just my 0.02?...

Patric

David Requena schrieb am 15.03.2010 13:30:
  

In the discussion bellow the term classpath is used in 2 distinct meanings:

"CLASSPATH" (in upper-case) is meant as an environment variable hinting
the jre
which actual logical "classpath" (in lower-case) to use while trying to
load classes.

    

- the people who know Java and their platform;
- the people coming from other Rexxen trying out the promise of the world of the Java VM and its standardized class libraries;
- passers-by maybe entering the world of programming or maybe disillusioned by the runtime performance of jruby and jpython (we have to work on that ;-))
  
      

I only see 2 groups.

"Passers-by entering the world of programming" not willing to invest
half an our reading some set-up instructions are not going to program
anything of any interest, in any language... ever! These should not
be our target audience.

    

As often is the case, the requirements and needs of these are different. People coming from Java (like myself, I did some Java before discovering NetRexx through Ed Tomlinson's Pipes for NetRexx package, but with earlier Rexx experience on MVS, OS/2 and NT) generally have no issues, drop the jar somewhere, edit the classpath and go. After some reflection and re-reading of past messages I now do agree that the first group does not need to be catered for at all, but the others do. The second group can be catered for with correct and elaborate instructions. My worries here concern the last mentioned group, the passers-by. I am passing by a lot of languages and compilers, and the number one put-off to try and install some compiler is a long list of instructions - there is even some equation in which the lenght of the instruction lists is equal to the failure rate.
  
      

Yes, programming is not easy. I agree it is not a thing for everyone.
Are we really trying to build a pedagogical programming language to
get the 5% people who actually become programmers at some point move
to some other "real language" latter?

    

Thus my proposal would be to have only a modest set of instructions added to the distribution archive; split up in separate pdf files for every major platform (Wintel, Linux-x86, Linux-Z, Aix, MacOSX). The 'elaborate sets' should be in the wiki on www.netrexx.org and linked to from these documents - Chip's excellent instruction/verification text should go in there.
  
      

I agree Chip made an excellent job. Some issues remain IIRC as there
was some hard-coded path in his batch file though.

    

The passers-by need to be catered for, if only because in the literature describing the history of Rexx, parallells with BASIC and Logo are drawn. We can say what we want about BASIC, the line numbered version, but it has attained its goal of enabling novices to program, and Logo is, I heard, even teachable to 5-years old (although I suspect that would be the crawling turtle part, not the recursive list hierarchy transversal part).
  
      

I learnt how to program in a CBM 64 using BASIC indeed. Many of my friends
also tried at the time. Most of them never got past:

10 PRINT"MY BROTHER IS AN AS*H*LE"
20 GOTO10

Some even reached

10 X$=0
20 X$=X$+1:PRINTX$;"MY BROTHER IS AN AS*H*LE"
30 GOTO20

The rest spent a lot of time studying memory maps, learning how to call
kernal
routines, etc. Then moved to 6502 assembler as soon as we could. Here
"the rest"
& "we" includes just me, what's the point in enabling my aunt Rosario
writing a
hello-world program at all?

The fact is that programming requires some learning effort. That's true
even when
trying to program your VCR or washing machine.

    

Different OS platforms have different strategies for the placement of the standard platform JVM (if any), (several) different JVM's can be installed on a platform, and some users may even switch JVMs during the development cycle, for example for the purpose of regression testing. The effects of the combination of, for example, a heterogeneous set of shared libraries and java archives can range from unnoticed to bewildering, to catastrophic.
  
      

I guess people with such a "complex" jvm set-up are coming from your
first group:
the one not experiencing any trouble setting the classpath right :-)

    

I think the principles on which we base the solutions for the encountered problems, must be to use environmental platform clues as much as possible, and the NetRexx translator itself must be very sparingly (and always relative to the environmental hint) guess where the correct libraries are. Even on MacOSX, where the Java locations were fixed for years, I am encountering two movements: the Apple team thinking of alternative packaging structure, moving eventually to mainstream *nix conventions, and in the meantime offering a program to locate the JAVA_HOME; and the open source Sun JDK7 releases being used as an alternative for people experimenting with InvokeDynamic, tail recursion and other great things to come to the JVM.

A subject of discussion is the use of the standard 'blessed' extension directories: they were not always there, they seem to multiply on some platforms, they might work differently among JVM vendors, and I see a high incidence of trouble with people using them. I do not have any problem with a user preference for their use, only I am loathe to advice to use them in the standard install document when this does not turn out to be a totally dependable mechanism. As a side thought - it might hinder understanding of the classpath model, which leads to trouble with the first application that is not in the default package.
  
      

I think is time for all of us to forget about both CLASSPATH and
extensions directories
once for all.
These just add complexity to an actually simple subject:

When you compile something in any language, you tell your compiler where
to find
needed libraries and or components. In java (and in NetRexx) this is done by
specifying a classpath at the command line. In fact it's even easier
than in most
other compiled languages, where you have to cater for declarations and
implementations
or binary objects separately. Yeah, that wouldn't be the case when
programming your
run of the mill hello-world program...

    

- a package-less 'nrc' class in the jar that has a main that calls the translator for a compile, and a .manifest file that declares that main, enabling users to start a compile with 'java -jar NetRexxC.jar SourceFile[.nrx]';
- platform dependent hints in the translator, relative to a JAVA_HOME environmental setting. For the open source releases we can have minor versions that address changes on the platforms;
  
      

Agree that could save some typing.

    

- a extra System.exec('java') when the Java compiler class cannot be found (funny enough a successful Java SDK enables the javac, which is a very thin native invoker executable for a Java program, to find its compiler class)
  
      

Hmmm... not sure I follow you here... Wouldn't a *clear* jdk requirement
save most of the
trouble people are experiencing?

    

One snag here is that fetching environment variables has been deprected in Java for a number of years (not every platform - phones -  have them) but since that seems to be reversed, and other language processors use them, I gather we are safe here for the future.
  
      

I don't think environment variables, as such, are deprecated at all.
This is a system
specific thing having nothing to do with java itself . It's just
CLASSPATH which has
been deprecated since at least java 2 version 1.2

    

For the moment, I would like to avoid a native or Java-installer approach that needs all this knowledge of platforms and possible combinations of JVM releases on machines out there. But I would certainly not oppose someone to pick this up and support this.
  
      

Agree this would involve platform specific code but the truth is that
NetRexx
today is being distributed with platform specific non-working scripts!

Here is my proposal:

- Distribute NetRexx with working scripts just dependent on a couple
environment
  variables. Say NRX_HOME and NRX_JDK.
- Bundle a simple NrxInstall package-less class in the main NetRexxC.jar
- Instruct the user to type "java -cp NetRexxC.jar NrxInstall

This would just ask 2 questions to the user:

- ¿Where is your jdk installed?

  A check is done for an actual jdk install there. If not present, we
ask again.
  Some intelligence could be built in as to a tries to automatically find an
  installed jdk.

- ¿Where do you want to install NetRexx?

  This defaults to where NetRexxC.jar is located for this execution of
NrxInstall. We
  already have this information from the command line. If user changes
this, then we
  copy NetRexxC.jar to desired location.

Finally NrxInstall intructs the user to put the second directory in his
PATH if he
wants to save some typing and what command to type if he does not.

That's it. Rerun this every time you mess with your java environment.

Honestly, this takes so much more to explain than to do. I would already
have done
it if I had had the time. Just too many balls airborne at once :-)


    

A separate 'Building applications for NetRexx' document, should contain chapters on package and directory structure, and touch subjects like the use of 'make', 'ant' and 'maven', class-in-source or not, generating Javadoc, how to handle dependencies, etc. On a side thought, 
      

Yeah, a Developers Guide would be great!

    

I wonder if our planned cpan-like repository could be a maven repository. The 'Building' document should explain about how to structure for NetRexx web apps using J2EE packaging conventions for JBoss, Glassfish and WebSphere. Obviously I would welcome volunteers to start building this information.
  
      

Hmm... not sure. Developing suitable Netbeans and Eclipse plugins for
NetRexx would cover
95% of this. And it would help raise mainstream NetRexx awareness sooo
muuch more!

    

Please let me know what you think - I already know that we would like the open source release to happen soon - but we can do so much as a community already before that happens. 
      

Fully agree

    

I will try to have the wiki up somewhere this weekend. It will be a JSPWiki, not the slickest around, but it enables us to extend it and brand the site NetRexx - powered. It will probably start out with three projects on it - installation, building and IDE - but even the table of contents will be user-editable.
  
      

That is great news indeed.



------------------------------------------------------------------------

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

    

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: GnuPT 2.5.2

iEYEARECAAYFAkueNy4ACgkQfGgGu8y7ypAdEgCfeUKi/AOlbOmRJDecJ2wic6/7
bJoAoLv5UaOcIKGTX1d6/sHOrLxlFVDW
=lMvn
-----END PGP SIGNATURE-----
_______________________________________________
Ibm-netrexx mailing list
[hidden email]



  

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Patric Bechtel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kermit Kiser schrieb am 15.03.2010 18:26:
> @ Patric ;
>
> I am a little puzzled. I looked at the Scala and Groovy languages and
> shells and I am not impressed.

Don't know why... but the Groovy shell just comes with Groovy and you
can type one line by another and see the results right away. Like in the
good old basic times... The installer itself is actually a breeze.

> They look much more difficult to use than NetRexx. Especially with the
> jEdit NetRexx plugins NetRexxDE and NetRexxScript. Granted, I already
> know how to use the jEdit editor environment so I am not the best judge
> of how difficult that is to setup and learn to use. But it is a fairly
> standard GUI type interface that should be usable with minimal
> directions to anyone with even a little modern computer experience.

Problem is, that you need to setup a JDK, then jEdit and make sure that
the JVM which starts jEdit is the JDK, not the JRE. Then the plugins
first, configure them with correct path (remember the "program files"
problem in the english windows version...), download the NetRexx zips,
unpack them into the jars directory and hope everything goes well.
I wouldn't say this is complicated, but there's smallish "annoyances",
like the space in "program files", the "I will copy the JRE exe to the
windows system directory" funny (*sarcastic laugh*).
Might be that I'm slightly exaggerating here, but if you try this on
MacOS (have fun with the various JVMs there), GNU/Linux
(RPM/Deb/whatever) and finally Solaris, or better, NetBSD or FreeBSD.

Take a view upon the solution I sketched on:
- - Install *any* JRE, IBM, Sun, whatever.
- - NetRexxC.jar, JDT Core and nr.jar, together <4MB.
- - start it with java -jar nr.jar -c -exec hello.nrx
Voila: No classpath hell, no path variables, nothing.

> And can't you run NetRexx in interpreter mode for an interactive shell?

Not yet. Maybe after we get the sources. Would be nice. :-)

> So why do you want something like the Scala/Groovy interfaces which
> don't seem nearly as easy to use as NetRexxScript where you can just
> type some NetRexx code and click a button to run it? What am I missing?

I agree on that. But the install is the main hassle. You have to compare
it with the things you get from M$: One (*huge*) download, one button
install, one platform. Huge marketing.
We have something special: cross platform, very, very small footprint.
People curious exploring this kind of platform should have a smooth
experience of "it's cute, it just works".


Patric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: GnuPT 2.5.2

iEYEARECAAYFAkueuiYACgkQfGgGu8y7ypA/EQCgzgXTbd2rAsDuJAWGgpRF0NQg
j3IAnjZ1umqd3715swqmlIIll0N9QQO/
=KPhS
-----END PGP SIGNATURE-----
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Tom Maynard]

Patric Bechtel wrote:
> Don't know why... but the Groovy shell just comes with Groovy and you
> can type one line by another and see the results right away. Like in the
> good old basic times... The installer itself is actually a breeze.
>
>  
I'm not trying to start any language wars here, but the BeanShell
"console" is even smaller than the Groovy version -- a single 275KB jar,
containing the whole language, the console, and probably more stuff that
I don't even know about.

Assuming you have a valid JDK installation (possibly JRE is enough, I
simply don't know), just drop the BSH jar on your desktop and
double-click it.  <POOF> The BeanShell console appears, ready to
interpret BeanShell commands.  There is no "installation" at all.

That said, I don't know of any language targeted for the JVM that
doesn't have a working JDK as a prerequisite.  If you're interested in
developing for the JVM, isn't the JDK the obvious first step?

Despite the fact that I've written miles of REXX code on the mainframe,
and can write REXX code in my sleep, I just might put myself in the
"NetRexx Passer-By" category.  I'm always on the lookout for a language
that will serve for utilitarian chores right here on the PC, have the
scalability to produce a GUI standalone when needed, and (ideally) move
to one of my Linux systems if necessary.  My brother has standardized on
Perl, I've got half a dozen languages installed here ... including NetRexx.

A simple download, with one-click installer, ready for development,
GUI/IDE or no, would win my vote -- and then the race is down to
language features and "likeability."  I already know I'm targeting the
JVM, I can deal with the Java installation -- which is, may I point out,
a download and one-click installation?  I view NetRexx (and Groovy, and
BeanShell, and ...) as "extensions" to the JVM.  And I still call myself
a "Passer-By."

I've got jEdit installed, too -- along with half a dozen other editors,
including NetBeans, IntelliJ, ..., you name it.  And I'm just an
"interested amateur" ... or "tyro."  Getting NetRexx up and running was
more difficult, and took longer -- even with careful perusal of the doc
-- than any of the others (all one-click installs) combined.  I'm still
not sure I have it right, and I installed it in every "JRE" directory on
my system (there are two).

Alright, my rant has ended.  I got my USD 0,02 worth.  But that's the
honest opinion of an otherwise uninvolved individual.  As a group, focus
on installation and delivering an environment wherein an individual can
play with the language ... all as simply (one click!) as possible.

Tom.


_______________________________________________
Ibm-netrexx mailing list
[hidden email]