Modified NetRexxC.cmd

[Anthony B. Coates]

At the risk of seeming unduly pretentious, I have attached a modified version
of "NetRexxC.cmd" in the hope that some of you might find it useful.  There are
two changes to the original

(i) it doesn't recompile your NetRexx file unless necessary (based on
timestamps), though you can override this by adding a "-force" flag;

(ii) it allows you to pass run-time arguments; anything that comes after "--"
(two dashes) is assumed to be a run-time argument.

I have found these modifications to be useful for the kinds of things I do,
anyway.  By the way, has anyone implemented something more along the lines of
the way the Python command line works, that files are automatically compiled as
needed (and only if needed), and parameters are all run-time parameters, with
settings dealt with otherwise (e.g. via environment variables).  If not, would
anyone be interested in such a thing for NetRexx?  Or am I the only one who
likes that kind of "batch-file" operation?

        Cheers,
                        Tony.

** Anthony B. Coates
** Software Engineer (Java).  This is a 100% Pure Java e-mail.
** <mailto:[hidden email]>

[mcbrides]

>At the risk of seeming unduly pretentious, I have attached a modified version
>of "NetRexxC.cmd" in the hope that some of you might find it useful.  There are
>two changes to the original
>
>(i) it doesn't recompile your NetRexx file unless necessary (based on
>timestamps), though you can override this by adding a "-force" flag;
>
>(ii) it allows you to pass run-time arguments; anything that comes after "--"
>(two dashes) is assumed to be a run-time argument.
>
>I have found these modifications to be useful for the kinds of things I do,
>anyway.  By the way, has anyone implemented something more along the lines of
>the way the Python command line works, that files are automatically compiled as
>needed (and only if needed), and parameters are all run-time parameters, with
>settings dealt with otherwise (e.g. via environment variables).  If not, would
>anyone be interested in such a thing for NetRexx?

Kinda' like a MAKE for NetRexx? I'd be very interested. This is one of those
projects that I'd love to spend some time on, but don't have enough to even sit
down and outline the project...

All I'd have to have is a routine that would look at available source code
(*.nrx) and compare all the classes in them to the actual class files in the
same directory... compiling the source if it's newer than the class file or
contains a class that doesn't exist. Hmmm... sounds easy... :')

>Or am I the only one who likes that kind of "batch-file" operation?
>

No, you're not alone. I have some netrexx source to share with you for the
above project. It's a client/server app that talks across a socket via
localhost. The client submits a source file to the server and the server runs
NetRexx on it. The server is threaded and once the compile is started, the
client and server are freed up to process more jobs or whatever. Runs great,
as a copy of the JVM is continously loaded, runnig the server. Compiles are
almost instantly started.

It'd make a nice addition to a NetRexx Make application.


--

/--------------------\
| Jerry McBride      |
| [hidden email] |
\--------------------/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Anthony B. Coates]

** Reply to message from "Anthony B. Coates" <[hidden email]> on Sat,
26 Jun 1999 16:57:11 AET

A followup to my earlier posting:

> At the risk of seeming unduly pretentious, I have attached a modified version
> of "NetRexxC.cmd" in the hope that some of you might find it useful.  There
are
> two changes to the original

As MFC has pointed out to me, I really should have changed the name of the
modified "NetRexxC.cmd" before posting it, so he knows which file is at fault if
he gets feedback in the future about a bug or other problem.  So, if you decide
to try out my modified "NetRexxC.cmd", *please* rename it to

                        NetRexxABC.cmd

first, so that the difference is obvious, and don't overwrite the original
"NetRexxC.cmd".  Thanks a lot, and my apologies to MFC for not thinking about
this before posting the modified file.

        Cheers,
                        Tony.

** Anthony B. Coates
** Software Engineer (Java).  This is a 100% Pure Java e-mail.
** <mailto:[hidden email]>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Martin Lafaix]

> From: [hidden email]
> All I'd have to have is a routine that would look at available source code
> (*.nrx) and compare all the classes in them to the actual class files in the
> same directory... compiling the source if it's newer than the class file or
> contains a class that doesn't exist. Hmmm... sounds easy... :')

Well, a "make" utility has to be as simple as possible (from the
developer's point of view), but not too simple (from the user's
point of view).  Your idea is too simple :-)

Recompiling the modified files is indeed something to be done
(even if it's not in the absolute always necessary, we at least
have to parse them to find that out, so compiling them does not
waste that much).  But we also need to recompile the "dependent"
unmodified classes.

For example, if we have the following two classes:

  -- a.nrx

  class a

    properties indirect
    foo = byte

  -- b.nrx

  [...]
  bar = foo()
  bar.setFoo(5)

We can compile both of them, and all is fine.  But now, let's
modify a.nrx, so that foo becomes an int instead of a byte.
Our beloved "make" utility would have to recompile b.nrx too to
please us completely.  If it doesn't, then running b.nrx will
produce an error ("Method not found").

Totally doable in Java, but not as simple as a simple timestamp
check :-)


Martin, whose spellchecker suggests "nit" for "int", so it looks
        like even my computer thinks I'm nitpicking again :-)
--
[hidden email]
Team OS/2
http://www.multimania.com/lafaix

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[mcbrides]

>
>> From: [hidden email]
>> All I'd have to have is a routine that would look at available source code
>> (*.nrx) and compare all the classes in them to the actual class files in the
>> same directory... compiling the source if it's newer than the class file or
>> contains a class that doesn't exist. Hmmm... sounds easy... :')
>
>Well, a "make" utility has to be as simple as possible (from the
>developer's point of view), but not too simple (from the user's
>point of view).  Your idea is too simple :-)
>

Actually, as a first draft proposal, it read quite easily... :')

>Recompiling the modified files is indeed something to be done
>(even if it's not in the absolute always necessary, we at least
>have to parse them to find that out, so compiling them does not
>waste that much).  But we also need to recompile the "dependent"
>unmodified classes.
>

True. However I would have thought processing dependent/unmodified classes to be
a given behavior...

>Totally doable in Java, but not as simple as a simple timestamp
>check :-)
>

That would be in keeping with the way most make's work.

Thanks for the post, Martin. I appreciate your illumination.


--

/--------------------\
| Jerry McBride      |
| [hidden email] |
\--------------------/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[dIon Gillard/Multitask Consulting/AU]

How about a mod/flag on NetRexxC to allow compilation by compilers other
than javac internally. I know it can be done by hand, but a flag would be
a lot better.

Jikes, for example has a depend option to compile dependent classes.

While I'm at it, how about a post/precompile commands as well. (Maybe in a
properties file, rather than flag?)

--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Play:        http://www.trongus.com




>
>> From: [hidden email]
>> All I'd have to have is a routine that would look at available source
code
>> (*.nrx) and compare all the classes in them to the actual class files
in the
>> same directory... compiling the source if it's newer than the class
file or
>> contains a class that doesn't exist. Hmmm... sounds easy... :')
>
>Well, a "make" utility has to be as simple as possible (from the
>developer's point of view), but not too simple (from the user's
>point of view).  Your idea is too simple :-)
>

Actually, as a first draft proposal, it read quite easily... :')

>Recompiling the modified files is indeed something to be done
>(even if it's not in the absolute always necessary, we at least
>have to parse them to find that out, so compiling them does not
>waste that much).  But we also need to recompile the "dependent"
>unmodified classes.
>

True. However I would have thought processing dependent/unmodified classes
to be
a given behavior...

>Totally doable in Java, but not as simple as a simple timestamp
>check :-)
>

That would be in keeping with the way most make's work.

Thanks for the post, Martin. I appreciate your illumination.


--

/--------------------\
| Jerry McBride      |
| [hidden email] |
\--------------------/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note
to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Mike Cowlishaw-2]

> How about a mod/flag on NetRexxC to allow compilation by compilers other
> than javac internally. I know it can be done by hand, but a flag would be
> a lot better.

Hmm, to do that I'd have to predict in advance the syntax rules of all
compilers and their parameters.  Sounds like a no-win...

(It think it's reasonable to assume that the java comand is going to be
wrapped up in some kind of script, in which case the script can call the
alternative compiler easily enough -- though it does have to do a rename
first.)


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mike Cowlishaw, IBM Fellow
mailto:[hidden email]  --  http://www2.hursley.ibm.com


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Mike Cowlishaw-2]

something like:

  nrc -Dnetrexx.java.compiler=my.possibly.maybe.compiler a b c ...

:-))  Looks like a dog's dinner to me!   What's the capital D for?  Which
application gets the "a b c"?   How are the different semantics of
different  compilers allowed for?    As just one example:  javac expects
and requires that all source files have names that end in '.java'.  Others
don't (and shouldn't?).   Dependency resolution varies.  Some compilers
accept a list of names to compile.  Others accept wildcards (*foo.jav*).
Others want more than one source file to be listed in another file (or an
environment variable).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mike Cowlishaw, IBM Fellow
mailto:[hidden email]  --  http://www2.hursley.ibm.com


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Martin Lafaix]

> From: [hidden email]
>
> > How about a mod/flag on NetRexxC to allow compilation by compilers other
> > than javac internally. I know it can be done by hand, but a flag would be
> > a lot better.
>
> Hmm, to do that I'd have to predict in advance the syntax rules of all
> compilers and their parameters.  Sounds like a no-win...
>
> (It think it's reasonable to assume that the java comand is going to be
> wrapped up in some kind of script, in which case the script can call the
> alternative compiler easily enough -- though it does have to do a rename
> first.)

What about defining a simple interface specifying the methods
NetRexx expects, and allowing us to override the default by using
something like:

  nrc -Dnetrexx.java.compiler=my.possibly.maybe.compiler a b c ...

NetRexxC would check for the netrexx.java.compiler system
property.  If defined, it would load the given class (which would
be required to implement the interface) instead of the default
one.

Looks like a win-win to me :-)


Martin
--
[hidden email]
Team OS/2
http://www.multimania.com/lafaix

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[mcbrides]

Hey, "someone" quietly placed NR 1.149 on the hursley site and... no document
upgrades.

What's new with this release, Mike? :')


--

/--------------------\
| Jerry McBride      |
| [hidden email] |
\--------------------/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Mike Cowlishaw-2]

It's really just a refresh; the www2 server is now running on new hardware
(the old box only had a 120MB hard disk, which was getting a bit cramped
:-).

There's one new feature, though: the UNUSED keyword on PROPERTIES, for
example:

 properties constant private unused    -- present but not referenced
     -- Serialization version
     serialVersionUID=long 8245355804974198832

which stops the warning message being generated when a property is
intentionally not expected to be referenced.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mike Cowlishaw, IBM Fellow
mailto:[hidden email]  --  http://www2.hursley.ibm.com


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[K.-P. Kirchdoerfer]

On Sun, 11 Jul 1999 19:58:36 +0100, [hidden email] wrote:

>
>There's one new feature, though: the UNUSED keyword on PROPERTIES, for
>example:
>
> properties constant private unused    -- present but not referenced

Compared to 1.148 also option strictargs, or has this been deleted
again since the latest testversion of 1.149?

kp
--
K.P.Kirchdoerfer                      Voice:   [phone]
24116 Kiel                            E-Mail: [hidden email]

Mission Of Dead Souls



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Mike Cowlishaw-2]

The STRICTPROPS option is still there (in 1.149) .  Also not formally doc'd
yet.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mike Cowlishaw, IBM Fellow
mailto:[hidden email]  --  http://www2.hursley.ibm.com


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>