Eclipse compiler and NetRexx build

[Earl Hodil]

On Sep 5, 2012, at 1:45 PM, Robert Hamilton <[hidden email]> wrote:

> Was there a tab character in Punched Cards?
>  
Not that I remember. But, then, I was programming in assembler, so there wasn't any need for indentation.


Earl Hodil

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

[christel.u.w.pachl christel.u.w.pachl]

yes there was (on the drum controlling the movement) and id was immediately translated to spases :-)
---- Robert Hamilton <[hidden email]> schrieb:

> Was there a tab character in Punched Cards?
>
> Bob Hamilton
> Richardson Texas USA
>
> On Wed, Sep 5, 2012 at 9:13 AM, Bill Fenlason <[hidden email]> wrote:
>
> > And that was one of the worst technical management decisions in history -
> > not correcting a serious design flaw when it was still feasible to do so.
> >
> > On 9/5/2012 8:07 AM, rvjansen wrote:
> >
> >>
> >> Yes, the tabs are terrible; as the story goes, the guy who came up with
> >> make at Bell's labs realised this one morning, but could not change it
> >> anymore because he already had 9 users.
> >>
> >> best regards,
> >>
> >> René.
> >>
> >>
> >>
> >> On 2012-09-05 13:58, Bill Fenlason wrote:
> >>
> >>> PS Not to be overly opinionated, but I think that the use of tab
> >>> characters as delimiters in make is one of the worst design decisions
> >>> in history.  You can keep it!
> >>>
> >>
> > ______________________________**_________________
> > Ibm-netrexx mailing list
> > [hidden email]
> > Online Archive : http://ibm-netrexx.215625.n3.**nabble.com/<http://ibm-netrexx.215625.n3.nabble.com/>
> >
> >

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

[Mike Cowlishaw]

 
> Not that I remember. But, then, I was programming in
> assembler, so there wasn't any need for indentation.

I beg to disagree; I use[d] indention in assembler code, and it is just as
useful there as in any other programming language.

Mike

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

[billfen]

My old green card (yellow book) says the EBCDIC tab 05 was a 12-5-9
punch.  The ASCII tab 09 was a 12-1-8-9 punch.

On 9/5/2012 2:12 PM, Earl Hodil wrote:

> On Sep 5, 2012, at 1:45 PM, Robert Hamilton <[hidden email]> wrote:
>
>> Was there a tab character in Punched Cards?
>>  
> Not that I remember. But, then, I was programming in assembler, so there wasn't any need for indentation.
>
>
> Earl Hodil
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2197 / Virus Database: 2437/5250 - Release Date: 09/05/12
>
>

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

[Robert L Hamilton]

And, what would be the purpose of TAB in punched cards?  I have worked for both IBM and Bell Labs but that was over 50 yrs ago but I remember each was terrified of the other stealing technology. I always wondered who would steal punched cards which went back before the WW II,  but The LAbs were analyzing cards to see how they were made.  Finally, IBM and AT&T came to some sort of agreement.  This was during the 1960s.

 

Bob Hamilton, Engineer

Richardson Texas USA

On Wed, Sep 5, 2012 at 1:12 PM, Earl Hodil <[hidden email]> wrote:

On Sep 5, 2012, at 1:45 PM, Robert Hamilton <[hidden email]> wrote:

> Was there a tab character in Punched Cards?
>

Not that I remember. But, then, I was programming in assembler, so there wasn't any need for indentation.


Earl Hodil

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

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

[christel.u.w.pachl christel.u.w.pachl]

---- Robert Hamilton <[hidden email]> schrieb:
> And, what would be the purpose of TAB in punched cards?  
I guess the program reading the card could interpret them and indent properly.
But Mike will tell.

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

[George Hovey-2]

I was the only programmer at our (small) company who knew how to prepare a drum card (a template controlling tabbing), or use a keypunch for that matter.  This gave me more frequent access to our 1620 than the other programmers because I didn't have to wait for the keypunch girls to make my corrections.  Cards were processed by two girls; one typed the programmer's coding form into a keypunch, and the second typed the same thing into a verifier, which looked externally the same as the keypunch, but just sounded a buzzer if the card and the second girl didn't agree.

Nothing magical about indentation - an exact image of the card was printed.

Tab cards were used in the 1890 census and were a great step forward.

I can remember grizzled tab room guys looking askance at the new young programmers, and with good reason -- they were all gone in a couple of years.

On Wed, Sep 5, 2012 at 2:38 PM, Walter Pachl <[hidden email]> wrote:

---- Robert Hamilton <[hidden email]> schrieb:

> And, what would be the purpose of TAB in punched cards?

I guess the program reading the card could interpret them and indent properly.
But Mike will tell.

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

--
"One can live magnificently in this world if one knows how to work and how to love."  --  Leo Tolstoy

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

[Tom Maynard]

On 09/05/2012 06:40 AM, rvjansen wrote:
> I have grown quite fond of Git over the last year, and I see a
> definite possibility for it in the future NetRexx repository.

I second this opinion, wholeheartedly.  In many Java-based communities
Git reigns supreme ... customarily with an associated Wiki and forum for
expanded coverage and support.  An attached blog or two is also quite
common.

Tom.

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

[Kermit Kiser]

@ René -

The Eclipse changes to the after3.01 experimental branch have been
committed and the pre-built compiler/runtime jars are now updated on Kenai:

http://kenai.com/projects/netrexx-plus/downloads/directory/Experimental%20NetRexx%20Build

The after3.01 NetRexx build now defaults to use the included ecj
(Eclipse) compiler.

The ant-netrexx task now accepts a "javacompiler" attribute which allows
dynamic selection of the compiler for each Ant compile step in a build.
The Ant properties I mentioned before are still valid but the attribute
will override them. Here is an example using the new attribute:

<target name="compile">
     <netrexxc srcDir="/source" includes="*.nrx" javacompiler="ecj" />
   </target>

BTW: I agree on the options stuff but I recommend that the documentation
include a nice table showing which options are valid where. In this case
the enhanced clarity outweighs the philosophy of never putting
information in more than one place in the documentation.

-- Kermit


On 9/2/2012 8:31 PM, rvjansen wrote:

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

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

[Kermit Kiser]

Hi Bill -

If I understand correctly, you seem to be talking about helping the
developers of the NetRexx language itself. I am willing to assist you if
I can in any way, including making changes to the build, ant task,
compiler, etc. I am even trying to learn Eclipse in my spare time.

That said, I have to be honest with you - there are around 10 developers
for NetRexx and associated tools including yourself (David, René,
Patric, Marc, Kermit, Bill, Chip, Tom, Thomas, any others I forgot?).
Only René and I actually seem to have much time to make any changes to
the source code right now and we are just nibbling around the edge.
Neither of us is much of an Eclipse user currently. Don't let that stop
you from what you are pursuing - we are still mostly in a "build it,
they will come" mode now and it could be very valuable later.

But I think your work is one of the most important pieces of our puzzle
because many Java programmers use Eclipse and interoperability with
NetRexx there is a big win! What I am trying to say is that I suggest
that you focus on helping programmers who code in NetRexx and don't
worry too much about the language developers for now. We spend weeks to
months, even years discussing any changes to NetRexx, then a developer
spends weeks to months researching the code and exploring the
ramifications of any changes to it, followed by a couple of days
changing and testing and documenting and publishing the changes, etc. In
other words, if you can save me a few seconds of compile time, that is
great but it won't make much difference overall to NetRexx progress
because that is a tiny part of the whole effort.

-- Kermit

On 9/4/2012 8:34 PM, Bill Fenlason wrote:

> Kermit,
>
> Basically what I want is for it to be easy for an Eclipse or NetBeans
> IDE user to be able to download the netrexxc source and immediately be
> able to take advantage of the IDE.
>
> For Eclipse that means automatic builds. (18 seconds doesn't sound
> long, but I  think it is quite long compared to none.)  And it also
> means immediate use of the Java Development Environment (JDE) and
> debugger for the Java code.  The whole point of Eclipse is immediate
> feedback, without the need to stop and do builds. Everything in the
> project is up to date, all the time.
>
> As a current JDE example,  suppose you have a method in one Java
> module, and calls to that method from several of the dozens of other
> Java modules in the project.  Suppose you change the method to add a
> parameter.  What happens when you click C-s to save the file?  You are
> told instantly exactly which other modules have to be changed because
> error messages are displayed in the "Problems" window.
>
> All you have to do to edit those instances is to click on each error
> message - a new edit window takes you there.  When the call is fixed,
> the error message goes away.  Then when that is done, click F11 to run
> or debug the program.
>
> How does the JDE accomplish that?  Obviously all the Java source and
> classes are kept around and the compiles and build are done
> automatically and constantly with every change.
>
> What I want to do in the long run is to provide the same kind of
> development environment for NetRexx code.
>
> Here is another example.  As an Eclipse user, you want to develop a
> test version of the compiler.  Here are the only steps that should be
> necessary: Type in the SVN repository name, and download the Eclipse
> project for netrexxc.  Open RxTranslator.nrx to edit it. Modify the
> banner (logo) message.  C-s to save the file.  Open Hello.nrx.  Click
> interpret or compile (with new compiler) to test the change.  The new
> banner is displayed in the console window (before "hello").
>
> No other steps should be necessary - no builds - just immediate !
> results.  Then if there is a misspelled word in the new banner, all
> that has to be done is to change it - that souce file is still open,
> etc., and if a syntax error is made, you know immediately, (it is
> underlined) and you don't even have to save the file.
>
> Except for the download, you could probably do the whole thing in less
> than 18 seconds.
>
> And if you are a developer, all you have to do is click "team" and
> then "commit" and "OK", and you are done.
>
> On 9/4/2012 8:23 PM, Kermit Kiser wrote:
>> Bill --
>>
>> I am not quite sure what you wish to accomplish here. Is this about
>> incremental changes and testing for the compiler/runtime modules? A
>> complete build including javadocs only takes 18 seconds on my dev box
>> so I have not seen any real need for that personally. Here is my view
>> on some of this stuff for what it is worth:
>>
>> I don't know why the \src directory is used other than legacy and
>> clarity of purpose. The name is irrelevant to the build as long as
>> the Ant build.xml knows what it is. \nrx would work fine if there is
>> some important need to change it.
>>
>> The build uses the \build\classes directory only to generate the
>> distribution jar files and the javadoc files. The nrx files don't
>> really need to be kept there for that phase and the whole directory
>> should probably be deleted at the end of the build unless someone
>> really wants to go back and look at the generated Java code for some
>> reason. In fact the whole \build directory is only a temporary
>> structure to make it easy to construct distribution packages for the
>> end users.
>>
>> Why do you want to save the java and class files after the compiler
>> and runtime jars and the javadocs have been built from them? BTW -
>> the new NetRexx coded Ant task does include your enhancement to
>> specify different directory names for the different file types but it
>> was not used in the build in order to remain compatible with earlier
>> versions.
>>
>> There is room for changes in the build if that can help any of our
>> language/compiler developers who want to use Eclipse but I don't
>> think it makes any difference to most NetRexx programmers.
>>
>> -- Kermit
>>
>>
>> On 9/4/2012 12:07 AM, Bill Fenlason wrote:
>>> Marc, I agree - using the same folder for both nrx and java files is
>>> not a good idea.  I said that because that might be the easiest
>>> approach.
>>>
>>> Usually Java is in a \src directory, and I'm not sure if the NetRexx
>>> files should be in \src or in a different directory like \nrx or
>>> whatever.  No doubt there can be a way to have the directory names
>>> as user specified, and can be either different or the same in any
>>> combination.
>>>
>>> The current Ant build uses the \src directory for the nrx files, and
>>> the \build\classes directory for both the java and class files and
>>> copies of the nrx files.
>>>
>>> I think using \src for the nrx files, \bin for the class files and
>>> something like \java for the java files might be reasonable, but as
>>> I said, I haven't gotten into it yet. Ideally each of the three
>>> directory names could be user specified.  (I did that with my
>>> netrexx3 Ant task.  I'm not sure if the new Ant task - written in
>>> NetRexx - does it that way.  Rene? Kermit?)
>>>
>>> What is the most common approach used?  Do most users just use \src
>>> for the nrx files and let the Ant build do the rest?
>>>
>>> From an Eclipse standpoint, I think having the java and class files
>>> in the same directory is not a good idea - the Eclipse convention is
>>> \src and \bin but I think they can be user specified.
>>>
>>> On 9/4/2012 4:36 AM, Marc Remes wrote:
>>>> On 09/03/2012 01:21 PM, Bill Fenlason wrote:
>>>>> The differences would probably be to include both the nrx and java
>>>>> files in the src directory structure and the use of
>>>>> the bin directory for the class files rather than the build
>>>>> directory structure.
>>>>
>>>> I am a bit opposed to have real source files and generated ones in
>>>> the same directory.
>>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>

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

[rvjansen]

Yes, I have heard about GitHub also -- but what I meant in this case is
Git as the version management system at the core of it. Very, very fast,
easy branching, apache-plugin less server to maintain (can run over ssh,
which you might have running anyway). Not much of a learning curve
starting from cvs-svn.

But let's wait and see what Kenai does. A move will be painful and not
the best way to spend our time right now. Wiki and forum are in our very
near future, but hosted by RexxLA; and open for everyone.

best regards,

René.

On 2012-09-06 02:47, Tom Maynard wrote:

> On 09/05/2012 06:40 AM, rvjansen wrote:
>> I have grown quite fond of Git over the last year, and I see a
>> definite possibility for it in the future NetRexx repository.
>
> I second this opinion, wholeheartedly.  In many Java-based
> communities Git reigns supreme ... customarily with an associated
> Wiki
> and forum for expanded coverage and support.  An attached blog or two
> is also quite common.
>
> Tom.
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

On 2012-09-06 02:47, Tom Maynard wrote:

> On 09/05/2012 06:40 AM, rvjansen wrote:
>> I have grown quite fond of Git over the last year, and I see a
>> definite possibility for it in the future NetRexx repository.
>
> I second this opinion, wholeheartedly.  In many Java-based
> communities Git reigns supreme ... customarily with an associated
> Wiki
> and forum for expanded coverage and support.  An attached blog or two
> is also quite common.
>
> Tom.
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

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

[rvjansen]

Thanks Kermit,

I'll make a nice table out of it and will include it in both documents.

René.


On 2012-09-06 06:06, Kermit Kiser wrote:

> @ René -
>
> The Eclipse changes to the after3.01 experimental branch have been
> committed and the pre-built compiler/runtime jars are now updated on
> Kenai:
>
>
> http://kenai.com/projects/netrexx-plus/downloads/directory/Experimental%20NetRexx%20Build
>
> The after3.01 NetRexx build now defaults to use the included ecj
> (Eclipse) compiler.
>
> The ant-netrexx task now accepts a "javacompiler" attribute which
> allows dynamic selection of the compiler for each Ant compile step in
> a build. The Ant properties I mentioned before are still valid but
> the
> attribute will override them. Here is an example using the new
> attribute:
>
> <target name="compile">
>     <netrexxc srcDir="/source" includes="*.nrx" javacompiler="ecj" />
>   </target>
>
> BTW: I agree on the options stuff but I recommend that the
> documentation include a nice table showing which options are valid
> where. In this case the enhanced clarity outweighs the philosophy of
> never putting information in more than one place in the
> documentation.
>
> -- Kermit
>
>
> On 9/2/2012 8:31 PM, rvjansen wrote:
>> Hi Kermit,
>>
>> thanks for looking into this, and for the rediscovery of the
>> netrexx_java variable. I have used it once, years ago and have
>> subsequently forgotten all about it, skipping NetRexxC.sh most of the
>> time. I will add this to the Quick Start Guide; I am surprised ant
>> does not give easy access to java environment options - but thanks for
>> fixing that.
>>
>> We can have a new option, so we cater for all the ways that we can
>> specify the backend compiler. My impression, however, is that the
>> 'options' mechanism crosses the boundaries between the language and
>> the runtime, and that choice of a backend compiler is something better
>> left out of the program source, for portability reasons. But I am not
>> opposed to it; we do need to put it on the agenda for the ARB however.
>>
>> On a side note, I think we do need to review all of the options
>> statements somewhere soon; there are/have been some slight problems
>> with precedence, and I am not unsympathetic to some of the claims that
>> the consequences of flipping options binary can be explained with more
>> clarity, or need additional treatment to keep the meaning of the
>> source program stable. Also, with options utf8 turning out to be
>> non-optional on the command line when specified in the program source,
>> we could look into getting rid of it entirely (by having it enabled as
>> standard, maybe allowing more unicode encodings in a standard way - I
>> do not know the drawbacks - a standard grammar would do some slower
>> scanning with larger characters set space so I can imagine NetRexx
>> also does).
>>
>> Looking forward to your commits,
>>
>> best regards,
>>
>> René.
>>
>> On 2012-09-01 04:42, Kermit Kiser wrote:
>>> René --
>>>
>>> I have merged the changes to support the Eclipse compiler into the
>>> "after3.01" experimental NetRexx branch and tested them
>>> successfully.
>>> However, I discovered that there is no way to pass the
>>> "nrx.compiler"
>>> Java system property from an Ant build to NetRexx. After modifying
>>> our
>>> NetRexx source for the ant-netrexx.jar task to set the Java
>>> property
>>> from an Ant property value, I was able to run the entire NetRexx
>>> build
>>> using the Eclipse Java compiler (ecj). The Ant property can be set
>>> using either a property name matching the existing ant.netrexx
>>> properties or using the same name as the Java property NetRexx
>>> looks
>>> for:
>>>
>>>   <property name="ant.netrexxc.javacompiler" value="ecj"/>
>>> or
>>>   <property name="nrx.compiler" value="ecj"/>
>>>
>>> Although this approach works OK, it has the drawback that Ant
>>> properties cannot be modified once set which means that all
>>> subsequent
>>> NetRexx compiles will use the same value. That may not be flexible
>>> enough for all cases. Also the NetRexx compiler API has no
>>> provision
>>> for selecting the compiler. For these reasons, I suggest that we
>>> consider a new compiler option to specify the Java compiler.
>>>
>>> One more thing I discovered about this option: Since the
>>> distributed
>>> NetRexxC compile scripts pass the environment variable
>>> "netrexx_java"
>>> to the Java VM at start, if there is no need for alternate NetRexx
>>> compiles on a system, the compiler selection can be placed in the
>>> environment and no change to the NetRexxC script is required. In
>>> Windows for example:
>>>
>>> set netrexx_java=-Dnrx.compile=ecj
>>>
>>> I will commit these changes soon.
>>>
>>> -- Kermit
>>>
>>>
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

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

[billfen]

Kermit,

As you know, sometimes programmers outside a project development team
download open source projects for investigation and to make special
versions.

Perhaps it is to provide functions that the base project does not
provide.  For example, I made a custom version of the JavaCC
compiler-compiler because my plugin had some special requirements. Other
times it is to make and test suggested enhancements or fixes. I recently
contributed syntax coloring for the Eclipse - JavaCC plugin, and am
developing the equivalent for the CUP-JFlex plugin. I know I'm not alone
in that kind of effort.

I realize that none of the current NetRexx developers use an IDE, and
most of them will never have any interest in doing so.  But for selfish
reasons and for the benefit of other non-netrexxc-developers who want to
hack the netrexxc code, I am lobbying for a repository setup that makes
it easy for programmers who use IDEs.

It isn't about saving seconds, it's about supporting the environments
that a growing number of programmers are used to.  If you want technical
talent to take an interest in netrexxc internals, it might pay to make
it easy for them.  You can build it and they may come, but they may also
walk away if it is too much work to adapt or the impression is "... how
20th century!".

I'm converting my downloaded netrexxc to an Eclipse project because I
occasionally need to insure compatibility with my plugin and I find the
IDE helpful.  (I even put in an occasional trace statement in the custom
compiler version :)  When I've figured out a setup which has a minimum
impact on the developers and provides an effective environment for IDE
users, I'll document and suggest it to the project.

In the meantime, as you suggest, I am concentrating on the plugin. That
is why I have not suggested (and provided code for) any netrexxc fixes
or enhancements.

Bill

On 9/6/2012 4:34 AM, Kermit Kiser wrote:

> Hi Bill -
>
> If I understand correctly, you seem to be talking about helping the
> developers of the NetRexx language itself. I am willing to assist you
> if I can in any way, including making changes to the build, ant task,
> compiler, etc. I am even trying to learn Eclipse in my spare time.
>
> That said, I have to be honest with you - there are around 10
> developers for NetRexx and associated tools including yourself (David,
> René, Patric, Marc, Kermit, Bill, Chip, Tom, Thomas, any others I
> forgot?). Only René and I actually seem to have much time to make any
> changes to the source code right now and we are just nibbling around
> the edge. Neither of us is much of an Eclipse user currently. Don't
> let that stop you from what you are pursuing - we are still mostly in
> a "build it, they will come" mode now and it could be very valuable
> later.
>
> But I think your work is one of the most important pieces of our
> puzzle because many Java programmers use Eclipse and interoperability
> with NetRexx there is a big win! What I am trying to say is that I
> suggest that you focus on helping programmers who code in NetRexx and
> don't worry too much about the language developers for now. We spend
> weeks to months, even years discussing any changes to NetRexx, then a
> developer spends weeks to months researching the code and exploring
> the ramifications of any changes to it, followed by a couple of days
> changing and testing and documenting and publishing the changes, etc.
> In other words, if you can save me a few seconds of compile time, that
> is great but it won't make much difference overall to NetRexx progress
> because that is a tiny part of the whole effort.
>
> -- Kermit

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

[rvjansen]

Bill,

let me add to Kermit's email that you have our full support.

best regards,

René.


On 2012-09-06 13:19, Bill Fenlason wrote:

> Kermit,
>
> As you know, sometimes programmers outside a project development team
> download open source projects for investigation and to make special
> versions.
>
> Perhaps it is to provide functions that the base project does not
> provide.  For example, I made a custom version of the JavaCC
> compiler-compiler because my plugin had some special requirements.
> Other times it is to make and test suggested enhancements or fixes. I
> recently contributed syntax coloring for the Eclipse - JavaCC plugin,
> and am developing the equivalent for the CUP-JFlex plugin. I know I'm
> not alone in that kind of effort.
>
> I realize that none of the current NetRexx developers use an IDE, and
> most of them will never have any interest in doing so.  But for
> selfish reasons and for the benefit of other non-netrexxc-developers
> who want to hack the netrexxc code, I am lobbying for a repository
> setup that makes it easy for programmers who use IDEs.
>
> It isn't about saving seconds, it's about supporting the environments
> that a growing number of programmers are used to.  If you want
> technical talent to take an interest in netrexxc internals, it might
> pay to make it easy for them.  You can build it and they may come,
> but
> they may also walk away if it is too much work to adapt or the
> impression is "... how 20th century!".
>
> I'm converting my downloaded netrexxc to an Eclipse project because I
> occasionally need to insure compatibility with my plugin and I find
> the IDE helpful.  (I even put in an occasional trace statement in the
> custom compiler version :)  When I've figured out a setup which has a
> minimum impact on the developers and provides an effective
> environment
> for IDE users, I'll document and suggest it to the project.
>
> In the meantime, as you suggest, I am concentrating on the plugin.
> That is why I have not suggested (and provided code for) any netrexxc
> fixes or enhancements.
>
> Bill
>
> On 9/6/2012 4:34 AM, Kermit Kiser wrote:
>> Hi Bill -
>>
>> If I understand correctly, you seem to be talking about helping the
>> developers of the NetRexx language itself. I am willing to assist you
>> if I can in any way, including making changes to the build, ant task,
>> compiler, etc. I am even trying to learn Eclipse in my spare time.
>>
>> That said, I have to be honest with you - there are around 10
>> developers for NetRexx and associated tools including yourself (David,
>> René, Patric, Marc, Kermit, Bill, Chip, Tom, Thomas, any others I
>> forgot?). Only René and I actually seem to have much time to make any
>> changes to the source code right now and we are just nibbling around
>> the edge. Neither of us is much of an Eclipse user currently. Don't
>> let that stop you from what you are pursuing - we are still mostly in
>> a "build it, they will come" mode now and it could be very valuable
>> later.
>>
>> But I think your work is one of the most important pieces of our
>> puzzle because many Java programmers use Eclipse and interoperability
>> with NetRexx there is a big win! What I am trying to say is that I
>> suggest that you focus on helping programmers who code in NetRexx and
>> don't worry too much about the language developers for now. We spend
>> weeks to months, even years discussing any changes to NetRexx, then a
>> developer spends weeks to months researching the code and exploring
>> the ramifications of any changes to it, followed by a couple of days
>> changing and testing and documenting and publishing the changes, etc.
>> In other words, if you can save me a few seconds of compile time, that
>> is great but it won't make much difference overall to NetRexx progress
>> because that is a tiny part of the whole effort.
>>
>> -- Kermit
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

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

[ThSITC]

Hi all,
   I am currently too busy in releasing my stuff in fill detail, BUT:

You should know that I did work on my private implementation of NetRexx,
*with some language additions I do feel to be needed*,
and with my own Parsing and Program Generating routines.

I did *bore you all* (in the past, only, I do hope) with this my Rey
Compiler announcements.

This year, I did make the decision that Rey will be a NEW Language, as I
do, for instance,
like to say:

x = 1300
x =  x - 17 %

I do think this usage of the percent sign is more *human* than using '%'
for *Integer Division*

There will be a Nrx2Rey.class, however ...

As it looks now, I will present the Rey Language at the upcoming RexxLA
meeting in Raleigh, then, 2013.

As my implementation does separate Parsing from Analysing from Code
Generation, as Rexx2Nrx
alsways did since early 2001, I will then use this, my own,
implementation to integrate it wherever I want....

Top on my list is NetBeans!

But, before *any* new actions, I will complemte the old ones, and trying
to earn MONEY
out of the past 7 Years of Development...

Have a nice day,
Thomas.
========================================================================

Am 06.09.2012 02:47, schrieb Tom Maynard:

> On 09/05/2012 06:40 AM, rvjansen wrote:
>> I have grown quite fond of Git over the last year, and I see a
>> definite possibility for it in the future NetRexx repository.
>
> I second this opinion, wholeheartedly.  In many Java-based communities
> Git reigns supreme ... customarily with an associated Wiki and forum
> for expanded coverage and support.  An attached blog or two is also
> quite common.
>
> Tom.
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
Thomas Schneider CEO ThSITC IT Consulting KG Erdbergstr. 52-60/1/13 1030
Wien Austria, Europe Skype ID: Thomas.Schneider.Wien Member of the Rexx
Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's
Team (www.netrexx.org)

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

[ThSITC]

*I* beg to disagree, Sir Mike F. Cowlishaw!

Since my 1. Days in Computers, *I* did refuse to learn Assembler at all!

Hence, whilst knowing and using quite a lot of different computer Languages,
I *can read* assembler, but did *always* refuse to *write 1 single line*
in Assembler...

But, as always, this is only my personal viewpoint, and shall *not* raise an
(un)anomous discusiion here, please!

Hence, please DROP this message, and do *NOT* reply to this my standpoint...

Massa Thomas   <grin>
==================================================================


Am 05.09.2012 20:21, schrieb Mike Cowlishaw:

>  
>> Not that I remember. But, then, I was programming in
>> assembler, so there wasn't any need for indentation.
> I beg to disagree; I use[d] indention in assembler code, and it is just as
> useful there as in any other programming language.
>
> Mike
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
Thomas Schneider CEO ThSITC IT Consulting KG Erdbergstr. 52-60/1/13 1030
Wien Austria, Europe Skype ID: Thomas.Schneider.Wien Member of the Rexx
Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's
Team (www.netrexx.org)

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