Python scripts for Radiance

[Georg_Mischler]

Hi again!

I have converted some of the original Radiance shell scripts into Python.
   https://github.com/gmischler/PyRad

The examples so far are exact drop-in replacements of the original csh
or Perl versions, but with some extra functionality and benefits.

* usage instructions (-H)
* progress report (-V)
* dry-run mode (-N)
* detailed error diagnostics
* compatible with Python 2.7 and Python 3.x
* self contained (all functionality can be combined in one file)
* truly cross-platform (no dependencies other than Python and Radiance)
* direct process management (no intermediate shell calls)
* immune to whitespace in file names
* tamper-proof use of temporary files
* instrumented for building a single-file *.exe with pyinstaller

The current selection is still small, the examples were chosen for
varying reasons:

* falsecolor.py
   This one has been sitting on my disk (in much less refined form) for
   many years. Now I've updated it to using color palettes and to satisfy
   all the points above.

* phisto.py
* rlux.py
* pveil.py
   Those three became test candidates because they are simple and have
   a straightforward command line.

I'm looking for ideas (and contributions) on where to continue next.

Good candidates are scripts that are commonly used.
It is also very helpful if a script includes documentation about what
it's actually supposed to do. Ideally with a set of test data to
verify that it really does that.
Actually, a solid set of test cases for the current collection would
be very helpful too.

Some of the csh/Perl scripts present a challenge, because they have
rather unconventional command lines. In those cases, we might want to
consider changing the interface to something more regular, provided
this is possible.

Not all of the existing scripts are really worth the effort.
The Python versions with the extra functionality are definitively not
as simple as the originals. Flexibility and safety has its price.
On the other hand, they will definitively be *much* easier to maintain.

Many of the current scripts (csh *and* Perl) blindly assume the
existence of a unix type shell, a number of other posix tools
(grep/awk/sed/etc.), and they often fail with spaces in file and
directory names. Fixing this would introduce additional overhead
in any language.

Why Python?

For developers, it is simply one of the most productive tools around.
Python has grown into one of the most popular languages just by its
practical merits, without any corporate backing, and without a very
strong web appeal.

Most Radiance users will already have it installed, no matter the
platform.

On unix, scripts can be invoked by "#!" (like any other).

Any script can be "compiled" into a standalone executable file.
This is important on Windows, because invoking scripts (Python,
*.bat, or otherwise) from within programs is a real hassle there.
In fact, it ended up being the simplest way to get winimage to
perform falsecolor analysis.
(This could also be done with Perl, but...)

I expect Python to play an increasing role in Radiance development in
the future, with or without my own involvement. So we might just as
well embrace it.

I would like to suggest adding Python versions of the most commonly
used scripts to the distribution. There are several possible
configurations how this could be done, so we'd have to discuss a
number of technical details first. And yes, verification before
inclusion would be an important step.

Opinions?

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

[Guglielmetti_Robert]

Schorsch, you're making the rest of us look like slackers!

I'm all about this move. When I added some new stuff that was written in
Ruby, it was less than enthusiastically adopted because of yet another
dependency; Perl had recently been added to the dependency list with the
new rtcontrib utilities. Axel Jacobs was his usual awesome self and
reimplemented my stuff in Perl (he's also responsible for the Perl
falsecolor), so we're back to the one dependency. I'm thrilled to see new
csh-based utilities now in Python (phisto was on my list of ones to
convert as well), and personally don't see the Python requirement a big
deal, but it is an additional requirement.

I think at this point the critical ones still implemented in Perl are
genBSDF and genskyvec, since you just added falsecolor. I would lobby for
objview/pict, and the derivatives I started in Ruby and Axel already
ported to Perl, ltview/pict.

- Rob

···

On 3/21/16, 10:02 AM, "Georg Mischler" <[email protected]> wrote:

Hi again!

I have converted some of the original Radiance shell scripts into
Python.
  https://github.com/gmischler/PyRad

The examples so far are exact drop-in replacements of the original csh
or Perl versions, but with some extra functionality and benefits.

* usage instructions (-H)
* progress report (-V)
* dry-run mode (-N)
* detailed error diagnostics
* compatible with Python 2.7 and Python 3.x
* self contained (all functionality can be combined in one file)
* truly cross-platform (no dependencies other than Python and Radiance)
* direct process management (no intermediate shell calls)
* immune to whitespace in file names
* tamper-proof use of temporary files
* instrumented for building a single-file *.exe with pyinstaller

The current selection is still small, the examples were chosen for
varying reasons:

* falsecolor.py
  This one has been sitting on my disk (in much less refined form) for
  many years. Now I've updated it to using color palettes and to satisfy
  all the points above.

* phisto.py
* rlux.py
* pveil.py
  Those three became test candidates because they are simple and have
  a straightforward command line.

I'm looking for ideas (and contributions) on where to continue next.

Good candidates are scripts that are commonly used.
It is also very helpful if a script includes documentation about what
it's actually supposed to do. Ideally with a set of test data to
verify that it really does that.
Actually, a solid set of test cases for the current collection would
be very helpful too.

Some of the csh/Perl scripts present a challenge, because they have
rather unconventional command lines. In those cases, we might want to
consider changing the interface to something more regular, provided
this is possible.

Not all of the existing scripts are really worth the effort.
The Python versions with the extra functionality are definitively not
as simple as the originals. Flexibility and safety has its price.
On the other hand, they will definitively be *much* easier to maintain.

Many of the current scripts (csh *and* Perl) blindly assume the
existence of a unix type shell, a number of other posix tools
(grep/awk/sed/etc.), and they often fail with spaces in file and
directory names. Fixing this would introduce additional overhead
in any language.

Why Python?

For developers, it is simply one of the most productive tools around.
Python has grown into one of the most popular languages just by its
practical merits, without any corporate backing, and without a very
strong web appeal.

Most Radiance users will already have it installed, no matter the
platform.

On unix, scripts can be invoked by "#!" (like any other).

Any script can be "compiled" into a standalone executable file.
This is important on Windows, because invoking scripts (Python,
*.bat, or otherwise) from within programs is a real hassle there.
In fact, it ended up being the simplest way to get winimage to
perform falsecolor analysis.
(This could also be done with Perl, but...)

I expect Python to play an increasing role in Radiance development in
the future, with or without my own involvement. So we might just as
well embrace it.

I would like to suggest adding Python versions of the most commonly
used scripts to the distribution. There are several possible
configurations how this could be done, so we'd have to discuss a
number of technical details first. And yes, verification before
inclusion would be an important step.

Opinions?

-schorsch

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

[Greg_Ward]

There is the downside that I don't know Python at all, and learning yet another object-oriented language with completely different syntax isn't high on my list of priorities. That said, if we can get past the support issues on various platforms, I have no problem with Schorsch and others making contributions they wish to support on an ongoing basis, or ones that are unlikely to require support.

For this reason, I don't have much enthusiasm for converting something as complex as genBSDF to Python, where I couldn't understand or fix any problems that arise in future.

Cheers,
-Greg

···

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 9:02:03 AM PDT

Hi again!

I have converted some of the original Radiance shell scripts into Python.
https://github.com/gmischler/PyRad

The examples so far are exact drop-in replacements of the original csh
or Perl versions, but with some extra functionality and benefits.

* usage instructions (-H)
* progress report (-V)
* dry-run mode (-N)
* detailed error diagnostics
* compatible with Python 2.7 and Python 3.x
* self contained (all functionality can be combined in one file)
* truly cross-platform (no dependencies other than Python and Radiance)
* direct process management (no intermediate shell calls)
* immune to whitespace in file names
* tamper-proof use of temporary files
* instrumented for building a single-file *.exe with pyinstaller

The current selection is still small, the examples were chosen for
varying reasons:

* falsecolor.py
This one has been sitting on my disk (in much less refined form) for
many years. Now I've updated it to using color palettes and to satisfy
all the points above.

* phisto.py
* rlux.py
* pveil.py
Those three became test candidates because they are simple and have
a straightforward command line.

I'm looking for ideas (and contributions) on where to continue next.

Good candidates are scripts that are commonly used.
It is also very helpful if a script includes documentation about what
it's actually supposed to do. Ideally with a set of test data to
verify that it really does that.
Actually, a solid set of test cases for the current collection would
be very helpful too.

Some of the csh/Perl scripts present a challenge, because they have
rather unconventional command lines. In those cases, we might want to
consider changing the interface to something more regular, provided
this is possible.

Not all of the existing scripts are really worth the effort.
The Python versions with the extra functionality are definitively not
as simple as the originals. Flexibility and safety has its price.
On the other hand, they will definitively be *much* easier to maintain.

Many of the current scripts (csh *and* Perl) blindly assume the
existence of a unix type shell, a number of other posix tools
(grep/awk/sed/etc.), and they often fail with spaces in file and
directory names. Fixing this would introduce additional overhead
in any language.

Why Python?

For developers, it is simply one of the most productive tools around.
Python has grown into one of the most popular languages just by its
practical merits, without any corporate backing, and without a very
strong web appeal.

Most Radiance users will already have it installed, no matter the
platform.

On unix, scripts can be invoked by "#!" (like any other).

Any script can be "compiled" into a standalone executable file.
This is important on Windows, because invoking scripts (Python,
*.bat, or otherwise) from within programs is a real hassle there.
In fact, it ended up being the simplest way to get winimage to
perform falsecolor analysis.
(This could also be done with Perl, but...)

I expect Python to play an increasing role in Radiance development in
the future, with or without my own involvement. So we might just as
well embrace it.

I would like to suggest adding Python versions of the most commonly
used scripts to the distribution. There are several possible
configurations how this could be done, so we'd have to discuss a
number of technical details first. And yes, verification before
inclusion would be an important step.

Opinions?

-schorsch

[Georg_Mischler]

Greg, someone of your capacity will be fluent in the Python syntax within
an hour, the object and exception system in a day, and the most elementary
parts of the library within a few days (the included library is so huge
that even experienced pythonistas will keep searching the documentation
for more arcane modules).

Python is "the language thet doesn't get in the way", and not another Perl.
You will very quickly have less problems debugging a Python program by
someone else, compared to a Perl program you have written yourself.
While I definitively understand your reluctance, I also think that in this
specific case you will find it to be unjustified.
And if you should still run into trouble, there are enough Radiance users
out there who are already very fluent and can help out.

So now we need a few more good conversion candidates with test cases.
Do you by chance still have any of the test cases you used to verify
the existing scripts when you created them?

-schorsch

···

Am 2016-03-21 20:44, schrieb Gregory J. Ward:

There is the downside that I don't know Python at all, and learning
yet another object-oriented language with completely different syntax
isn't high on my list of priorities. That said, if we can get past
the support issues on various platforms, I have no problem with
Schorsch and others making contributions they wish to support on an
ongoing basis, or ones that are unlikely to require support.

For this reason, I don't have much enthusiasm for converting something
as complex as genBSDF to Python, where I couldn't understand or fix
any problems that arise in future.

Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 9:02:03 AM PDT

Hi again!

I have converted some of the original Radiance shell scripts into Python.
https://github.com/gmischler/PyRad

The examples so far are exact drop-in replacements of the original csh
or Perl versions, but with some extra functionality and benefits.

* usage instructions (-H)
* progress report (-V)
* dry-run mode (-N)
* detailed error diagnostics
* compatible with Python 2.7 and Python 3.x
* self contained (all functionality can be combined in one file)
* truly cross-platform (no dependencies other than Python and Radiance)
* direct process management (no intermediate shell calls)
* immune to whitespace in file names
* tamper-proof use of temporary files
* instrumented for building a single-file *.exe with pyinstaller

The current selection is still small, the examples were chosen for
varying reasons:

* falsecolor.py
This one has been sitting on my disk (in much less refined form) for
many years. Now I've updated it to using color palettes and to satisfy
all the points above.

* phisto.py
* rlux.py
* pveil.py
Those three became test candidates because they are simple and have
a straightforward command line.

I'm looking for ideas (and contributions) on where to continue next.

Good candidates are scripts that are commonly used.
It is also very helpful if a script includes documentation about what
it's actually supposed to do. Ideally with a set of test data to
verify that it really does that.
Actually, a solid set of test cases for the current collection would
be very helpful too.

Some of the csh/Perl scripts present a challenge, because they have
rather unconventional command lines. In those cases, we might want to
consider changing the interface to something more regular, provided
this is possible.

Not all of the existing scripts are really worth the effort.
The Python versions with the extra functionality are definitively not
as simple as the originals. Flexibility and safety has its price.
On the other hand, they will definitively be *much* easier to maintain.

Many of the current scripts (csh *and* Perl) blindly assume the
existence of a unix type shell, a number of other posix tools
(grep/awk/sed/etc.), and they often fail with spaces in file and
directory names. Fixing this would introduce additional overhead
in any language.

Why Python?

For developers, it is simply one of the most productive tools around.
Python has grown into one of the most popular languages just by its
practical merits, without any corporate backing, and without a very
strong web appeal.

Most Radiance users will already have it installed, no matter the
platform.

On unix, scripts can be invoked by "#!" (like any other).

Any script can be "compiled" into a standalone executable file.
This is important on Windows, because invoking scripts (Python,
*.bat, or otherwise) from within programs is a real hassle there.
In fact, it ended up being the simplest way to get winimage to
perform falsecolor analysis.
(This could also be done with Perl, but...)

I expect Python to play an increasing role in Radiance development in
the future, with or without my own involvement. So we might just as
well embrace it.

I would like to suggest adding Python versions of the most commonly
used scripts to the distribution. There are several possible
configurations how this could be done, so we'd have to discuss a
number of technical details first. And yes, verification before
inclusion would be an important step.

Opinions?

-schorsch

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

[Wouter_Beck_Ascendil]

Dear Georg,

  I would vote for the glaze csh script.

  Best,

  Wouter

···

On 03/21/2016 05:02 PM, Georg Mischler wrote:

  Hi again!



  I have converted some of the original Radiance shell scripts into Python.

  � The examples so far are exact drop-in replacements of the original csh or Perl versions, but with some extra functionality and benefits. * usage instructions (-H) * progress report (-V) * dry-run mode (-N) * detailed error diagnostics * compatible with Python 2.7 and Python 3.x * self contained (all functionality can be combined in one file) * truly cross-platform (no dependencies other than Python and Radiance) * direct process management (no intermediate shell calls) * immune to whitespace in file names * tamper-proof use of temporary files * instrumented for building a single-file *.exe with pyinstaller The current selection is still small, the examples were chosen for varying reasons: * falsecolor.py � This one has been sitting on my disk (in much less refined form) for � many years. Now I've updated it to using color palettes and to satisfy � all the points above. * phisto.py * rlux.py * pveil.py � Those three became test candidates because they are simple and have � a straightforward command line. I'm looking for ideas (and contributions) on where to continue next. Good candidates are scripts that are commonly used. It is also very helpful if a script includes documentation about what it's actually supposed to do. Ideally with a set of test data to verify that it really does that. Actually, a solid set of test cases for the current collection would be very helpful too. Some of the csh/Perl scripts present a challenge, because they have rather unconventional command lines. In those cases, we might want to consider changing the interface to something more regular, provided this is possible. Not all of the existing scripts are really worth the effort. The Python versions with the extra functionality are definitively not as simple as the originals. Flexibility and safety has its price. On the other hand, they will definitively be *much* easier to maintain. Many of the current scripts (csh *and* Perl) blindly assume the existence of a unix type shell, a number of other posix tools (grep/awk/sed/etc.), and they often fail with spaces in file and directory names. Fixing this would introduce additional overhead in any language. Why Python? For developers, it is simply one of the most productive tools around. Python has grown into one of the most popular languages just by its practical merits, without any corporate backing, and without a very strong web appeal. Most Radiance users will already have it installed, no matter the platform. On unix, scripts can be invoked by "#!" (like any other). Any script can be "compiled" into a standalone executable file. This is important on Windows, because invoking scripts (Python, *.bat, or otherwise) from within programs is a real hassle there. In fact, it ended up being the simplest way to get winimage to perform falsecolor analysis. (This could also be done with Perl, but...) I expect Python to play an increasing role in Radiance development in the future, with or without my own involvement.� So we might just as well embrace it. I would like to suggest adding Python versions of the most commonly used scripts to the distribution. There are several possible configurations how this could be done, so we'd have to discuss a number of technical details first. And yes, verification before inclusion would be an important step. Opinions? -schorsch

https://github.com/gmischler/PyRad

[Greg_Ward]

Hmmm... Well, I may be a little thicker with respect to learning new languages than you give me credit for. Lately, I've been trying to pick up Java for one of my client projects and having a lot of trouble, despite (or because of?) its passing similarity to C++. Perl is relatively easy for me precisely because it doesn't have all the object-oriented stuff or extensive libraries. I always avoided the C++ STL because I never could understand what they wanted me to do with it. It's less a matter of language philosophy and more a matter of how much vocabulary/syntax one needs to master, because my mental capacity for "miscellaneous stuff" is severely limited. I never could get the hang of foreign languages because I can't remember vocabulary.

So, I stick by my preference not to rewrite all the existing Perl scripts as Python, except in cases where I am not needed for their future maintenance. I understand that it is important to move away from C-shell, and that's fine. Unfortunately, my ability to fix anything more than the way the Radiance tools get called in Python is currently zero, and looking at your new scripts, I don't see that changing anytime soon.

Also, I wish I had some test cases for these scripts, but I was never really good about that. I generally wrote something when I needed it or had an example ready, but I didn't have the foresight to keep those examples around, so I'm not much help there. Sorry!

-Greg

···

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 2:21:12 PM PDT

Greg, someone of your capacity will be fluent in the Python syntax within
an hour, the object and exception system in a day, and the most elementary
parts of the library within a few days (the included library is so huge
that even experienced pythonistas will keep searching the documentation
for more arcane modules).

Python is "the language thet doesn't get in the way", and not another Perl.
You will very quickly have less problems debugging a Python program by
someone else, compared to a Perl program you have written yourself.
While I definitively understand your reluctance, I also think that in this
specific case you will find it to be unjustified.
And if you should still run into trouble, there are enough Radiance users
out there who are already very fluent and can help out.

So now we need a few more good conversion candidates with test cases.
Do you by chance still have any of the test cases you used to verify
the existing scripts when you created them?

-schorsch

Am 2016-03-21 20:44, schrieb Gregory J. Ward:

There is the downside that I don't know Python at all, and learning
yet another object-oriented language with completely different syntax
isn't high on my list of priorities. That said, if we can get past
the support issues on various platforms, I have no problem with
Schorsch and others making contributions they wish to support on an
ongoing basis, or ones that are unlikely to require support.
For this reason, I don't have much enthusiasm for converting something
as complex as genBSDF to Python, where I couldn't understand or fix
any problems that arise in future.
Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 9:02:03 AM PDT
Hi again!
I have converted some of the original Radiance shell scripts into Python.
https://github.com/gmischler/PyRad
The examples so far are exact drop-in replacements of the original csh
or Perl versions, but with some extra functionality and benefits.
* usage instructions (-H)
* progress report (-V)
* dry-run mode (-N)
* detailed error diagnostics
* compatible with Python 2.7 and Python 3.x
* self contained (all functionality can be combined in one file)
* truly cross-platform (no dependencies other than Python and Radiance)
* direct process management (no intermediate shell calls)
* immune to whitespace in file names
* tamper-proof use of temporary files
* instrumented for building a single-file *.exe with pyinstaller
The current selection is still small, the examples were chosen for
varying reasons:
* falsecolor.py
This one has been sitting on my disk (in much less refined form) for
many years. Now I've updated it to using color palettes and to satisfy
all the points above.
* phisto.py
* rlux.py
* pveil.py
Those three became test candidates because they are simple and have
a straightforward command line.
I'm looking for ideas (and contributions) on where to continue next.
Good candidates are scripts that are commonly used.
It is also very helpful if a script includes documentation about what
it's actually supposed to do. Ideally with a set of test data to
verify that it really does that.
Actually, a solid set of test cases for the current collection would
be very helpful too.
Some of the csh/Perl scripts present a challenge, because they have
rather unconventional command lines. In those cases, we might want to
consider changing the interface to something more regular, provided
this is possible.
Not all of the existing scripts are really worth the effort.
The Python versions with the extra functionality are definitively not
as simple as the originals. Flexibility and safety has its price.
On the other hand, they will definitively be *much* easier to maintain.
Many of the current scripts (csh *and* Perl) blindly assume the
existence of a unix type shell, a number of other posix tools
(grep/awk/sed/etc.), and they often fail with spaces in file and
directory names. Fixing this would introduce additional overhead
in any language.
Why Python?
For developers, it is simply one of the most productive tools around.
Python has grown into one of the most popular languages just by its
practical merits, without any corporate backing, and without a very
strong web appeal.
Most Radiance users will already have it installed, no matter the
platform.
On unix, scripts can be invoked by "#!" (like any other).
Any script can be "compiled" into a standalone executable file.
This is important on Windows, because invoking scripts (Python,
*.bat, or otherwise) from within programs is a real hassle there.
In fact, it ended up being the simplest way to get winimage to
perform falsecolor analysis.
(This could also be done with Perl, but...)
I expect Python to play an increasing role in Radiance development in
the future, with or without my own involvement. So we might just as
well embrace it.
I would like to suggest adding Python versions of the most commonly
used scripts to the distribution. There are several possible
configurations how this could be done, so we'd have to discuss a
number of technical details first. And yes, verification before
inclusion would be an important step.
Opinions?
-schorsch

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

[Georg_Mischler]

You're arguing with some of the most syntactitcally complex aspects
of current programming languages here. (STL?!?)
In contrast, Pythons syntax was specifically designed to be easy to
understand and use (there's a lot of research into that).

Maybe you should just invest an hour and play through the tutorial
  https://docs.python.org/3/tutorial/ (also in the downloaded docs)
Then you may see firsthand that Python is really different from
all the horrible things you've already seen...

If you can't get your head wrapped around object oriented ideas,
Python won't force them onto you (other than Java). But if you want
to use them, they're much simpler to implement in Python.

Python is "the language that doesn't get in the way".

-schorsch

···

Am 2016-03-21 22:55, schrieb Gregory J. Ward:

Hmmm... Well, I may be a little thicker with respect to learning new
languages than you give me credit for. Lately, I've been trying to
pick up Java for one of my client projects and having a lot of
trouble, despite (or because of?) its passing similarity to C++. Perl
is relatively easy for me precisely because it doesn't have all the
object-oriented stuff or extensive libraries. I always avoided the
C++ STL because I never could understand what they wanted me to do
with it. It's less a matter of language philosophy and more a matter
of how much vocabulary/syntax one needs to master, because my mental
capacity for "miscellaneous stuff" is severely limited. I never could
get the hang of foreign languages because I can't remember vocabulary.

So, I stick by my preference not to rewrite all the existing Perl
scripts as Python, except in cases where I am not needed for their
future maintenance. I understand that it is important to move away
from C-shell, and that's fine. Unfortunately, my ability to fix
anything more than the way the Radiance tools get called in Python is
currently zero, and looking at your new scripts, I don't see that
changing anytime soon.

Also, I wish I had some test cases for these scripts, but I was never
really good about that. I generally wrote something when I needed it
or had an example ready, but I didn't have the foresight to keep those
examples around, so I'm not much help there. Sorry!

-Greg

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 2:21:12 PM PDT

Greg, someone of your capacity will be fluent in the Python syntax within
an hour, the object and exception system in a day, and the most elementary
parts of the library within a few days (the included library is so huge
that even experienced pythonistas will keep searching the documentation
for more arcane modules).

Python is "the language thet doesn't get in the way", and not another Perl.
You will very quickly have less problems debugging a Python program by
someone else, compared to a Perl program you have written yourself.
While I definitively understand your reluctance, I also think that in this
specific case you will find it to be unjustified.
And if you should still run into trouble, there are enough Radiance users
out there who are already very fluent and can help out.

So now we need a few more good conversion candidates with test cases.
Do you by chance still have any of the test cases you used to verify
the existing scripts when you created them?

-schorsch

Am 2016-03-21 20:44, schrieb Gregory J. Ward:

There is the downside that I don't know Python at all, and learning
yet another object-oriented language with completely different syntax
isn't high on my list of priorities. That said, if we can get past
the support issues on various platforms, I have no problem with
Schorsch and others making contributions they wish to support on an
ongoing basis, or ones that are unlikely to require support.
For this reason, I don't have much enthusiasm for converting something
as complex as genBSDF to Python, where I couldn't understand or fix
any problems that arise in future.
Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 9:02:03 AM PDT
Hi again!
I have converted some of the original Radiance shell scripts into Python.
https://github.com/gmischler/PyRad
The examples so far are exact drop-in replacements of the original csh
or Perl versions, but with some extra functionality and benefits.
* usage instructions (-H)
* progress report (-V)
* dry-run mode (-N)
* detailed error diagnostics
* compatible with Python 2.7 and Python 3.x
* self contained (all functionality can be combined in one file)
* truly cross-platform (no dependencies other than Python and Radiance)
* direct process management (no intermediate shell calls)
* immune to whitespace in file names
* tamper-proof use of temporary files
* instrumented for building a single-file *.exe with pyinstaller
The current selection is still small, the examples were chosen for
varying reasons:
* falsecolor.py
This one has been sitting on my disk (in much less refined form) for
many years. Now I've updated it to using color palettes and to satisfy
all the points above.
* phisto.py
* rlux.py
* pveil.py
Those three became test candidates because they are simple and have
a straightforward command line.
I'm looking for ideas (and contributions) on where to continue next.
Good candidates are scripts that are commonly used.
It is also very helpful if a script includes documentation about what
it's actually supposed to do. Ideally with a set of test data to
verify that it really does that.
Actually, a solid set of test cases for the current collection would
be very helpful too.
Some of the csh/Perl scripts present a challenge, because they have
rather unconventional command lines. In those cases, we might want to
consider changing the interface to something more regular, provided
this is possible.
Not all of the existing scripts are really worth the effort.
The Python versions with the extra functionality are definitively not
as simple as the originals. Flexibility and safety has its price.
On the other hand, they will definitively be *much* easier to maintain.
Many of the current scripts (csh *and* Perl) blindly assume the
existence of a unix type shell, a number of other posix tools
(grep/awk/sed/etc.), and they often fail with spaces in file and
directory names. Fixing this would introduce additional overhead
in any language.
Why Python?
For developers, it is simply one of the most productive tools around.
Python has grown into one of the most popular languages just by its
practical merits, without any corporate backing, and without a very
strong web appeal.
Most Radiance users will already have it installed, no matter the
platform.
On unix, scripts can be invoked by "#!" (like any other).
Any script can be "compiled" into a standalone executable file.
This is important on Windows, because invoking scripts (Python,
*.bat, or otherwise) from within programs is a real hassle there.
In fact, it ended up being the simplest way to get winimage to
perform falsecolor analysis.
(This could also be done with Perl, but...)
I expect Python to play an increasing role in Radiance development in
the future, with or without my own involvement. So we might just as
well embrace it.
I would like to suggest adding Python versions of the most commonly
used scripts to the distribution. There are several possible
configurations how this could be done, so we'd have to discuss a
number of technical details first. And yes, verification before
inclusion would be an important step.
Opinions?
-schorsch

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

[Greg_Ward]

All I can say is:

  SHORTPROGN = os.path.splitext(os.path.split(sys.argv[0])[1])[0]

···

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 4:22:47 PM PDT

You're arguing with some of the most syntactitcally complex aspects
of current programming languages here. (STL?!?)
In contrast, Pythons syntax was specifically designed to be easy to
understand and use (there's a lot of research into that).

Maybe you should just invest an hour and play through the tutorial
https://docs.python.org/3/tutorial/ (also in the downloaded docs)
Then you may see firsthand that Python is really different from
all the horrible things you've already seen...

If you can't get your head wrapped around object oriented ideas,
Python won't force them onto you (other than Java). But if you want
to use them, they're much simpler to implement in Python.

Python is "the language that doesn't get in the way".

-schorsch

Am 2016-03-21 22:55, schrieb Gregory J. Ward:

Hmmm... Well, I may be a little thicker with respect to learning new
languages than you give me credit for. Lately, I've been trying to
pick up Java for one of my client projects and having a lot of
trouble, despite (or because of?) its passing similarity to C++. Perl
is relatively easy for me precisely because it doesn't have all the
object-oriented stuff or extensive libraries. I always avoided the
C++ STL because I never could understand what they wanted me to do
with it. It's less a matter of language philosophy and more a matter
of how much vocabulary/syntax one needs to master, because my mental
capacity for "miscellaneous stuff" is severely limited. I never could
get the hang of foreign languages because I can't remember vocabulary.
So, I stick by my preference not to rewrite all the existing Perl
scripts as Python, except in cases where I am not needed for their
future maintenance. I understand that it is important to move away
from C-shell, and that's fine. Unfortunately, my ability to fix
anything more than the way the Radiance tools get called in Python is
currently zero, and looking at your new scripts, I don't see that
changing anytime soon.
Also, I wish I had some test cases for these scripts, but I was never
really good about that. I generally wrote something when I needed it
or had an example ready, but I didn't have the foresight to keep those
examples around, so I'm not much help there. Sorry!
-Greg

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 2:21:12 PM PDT
Greg, someone of your capacity will be fluent in the Python syntax within
an hour, the object and exception system in a day, and the most elementary
parts of the library within a few days (the included library is so huge
that even experienced pythonistas will keep searching the documentation
for more arcane modules).
Python is "the language thet doesn't get in the way", and not another Perl.
You will very quickly have less problems debugging a Python program by
someone else, compared to a Perl program you have written yourself.
While I definitively understand your reluctance, I also think that in this
specific case you will find it to be unjustified.
And if you should still run into trouble, there are enough Radiance users
out there who are already very fluent and can help out.
So now we need a few more good conversion candidates with test cases.
Do you by chance still have any of the test cases you used to verify
the existing scripts when you created them?
-schorsch
Am 2016-03-21 20:44, schrieb Gregory J. Ward:

There is the downside that I don't know Python at all, and learning
yet another object-oriented language with completely different syntax
isn't high on my list of priorities. That said, if we can get past
the support issues on various platforms, I have no problem with
Schorsch and others making contributions they wish to support on an
ongoing basis, or ones that are unlikely to require support.
For this reason, I don't have much enthusiasm for converting something
as complex as genBSDF to Python, where I couldn't understand or fix
any problems that arise in future.
Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 9:02:03 AM PDT
Hi again!
I have converted some of the original Radiance shell scripts into Python.
https://github.com/gmischler/PyRad
The examples so far are exact drop-in replacements of the original csh
or Perl versions, but with some extra functionality and benefits.
* usage instructions (-H)
* progress report (-V)
* dry-run mode (-N)
* detailed error diagnostics
* compatible with Python 2.7 and Python 3.x
* self contained (all functionality can be combined in one file)
* truly cross-platform (no dependencies other than Python and Radiance)
* direct process management (no intermediate shell calls)
* immune to whitespace in file names
* tamper-proof use of temporary files
* instrumented for building a single-file *.exe with pyinstaller
The current selection is still small, the examples were chosen for
varying reasons:
* falsecolor.py
This one has been sitting on my disk (in much less refined form) for
many years. Now I've updated it to using color palettes and to satisfy
all the points above.
* phisto.py
* rlux.py
* pveil.py
Those three became test candidates because they are simple and have
a straightforward command line.
I'm looking for ideas (and contributions) on where to continue next.
Good candidates are scripts that are commonly used.
It is also very helpful if a script includes documentation about what
it's actually supposed to do. Ideally with a set of test data to
verify that it really does that.
Actually, a solid set of test cases for the current collection would
be very helpful too.
Some of the csh/Perl scripts present a challenge, because they have
rather unconventional command lines. In those cases, we might want to
consider changing the interface to something more regular, provided
this is possible.
Not all of the existing scripts are really worth the effort.
The Python versions with the extra functionality are definitively not
as simple as the originals. Flexibility and safety has its price.
On the other hand, they will definitively be *much* easier to maintain.
Many of the current scripts (csh *and* Perl) blindly assume the
existence of a unix type shell, a number of other posix tools
(grep/awk/sed/etc.), and they often fail with spaces in file and
directory names. Fixing this would introduce additional overhead
in any language.
Why Python?
For developers, it is simply one of the most productive tools around.
Python has grown into one of the most popular languages just by its
practical merits, without any corporate backing, and without a very
strong web appeal.
Most Radiance users will already have it installed, no matter the
platform.
On unix, scripts can be invoked by "#!" (like any other).
Any script can be "compiled" into a standalone executable file.
This is important on Windows, because invoking scripts (Python,
*.bat, or otherwise) from within programs is a real hassle there.
In fact, it ended up being the simplest way to get winimage to
perform falsecolor analysis.
(This could also be done with Perl, but...)
I expect Python to play an increasing role in Radiance development in
the future, with or without my own involvement. So we might just as
well embrace it.
I would like to suggest adding Python versions of the most commonly
used scripts to the distribution. There are several possible
configurations how this could be done, so we'd have to discuss a
number of technical details first. And yes, verification before
inclusion would be an important step.
Opinions?
-schorsch

[Georg_Mischler]

If that exceeds your syntax input queue, then you're getting old!

···

Am 2016-03-22 00:52, schrieb Gregory J. Ward:

All I can say is:

  SHORTPROGN = os.path.splitext(os.path.split(sys.argv[0])[1])[0]

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 4:22:47 PM PDT

You're arguing with some of the most syntactitcally complex aspects
of current programming languages here. (STL?!?)
In contrast, Pythons syntax was specifically designed to be easy to
understand and use (there's a lot of research into that).

Maybe you should just invest an hour and play through the tutorial
https://docs.python.org/3/tutorial/ (also in the downloaded docs)
Then you may see firsthand that Python is really different from
all the horrible things you've already seen...

If you can't get your head wrapped around object oriented ideas,
Python won't force them onto you (other than Java). But if you want
to use them, they're much simpler to implement in Python.

Python is "the language that doesn't get in the way".

-schorsch

Am 2016-03-21 22:55, schrieb Gregory J. Ward:

Hmmm... Well, I may be a little thicker with respect to learning new
languages than you give me credit for. Lately, I've been trying to
pick up Java for one of my client projects and having a lot of
trouble, despite (or because of?) its passing similarity to C++. Perl
is relatively easy for me precisely because it doesn't have all the
object-oriented stuff or extensive libraries. I always avoided the
C++ STL because I never could understand what they wanted me to do
with it. It's less a matter of language philosophy and more a matter
of how much vocabulary/syntax one needs to master, because my mental
capacity for "miscellaneous stuff" is severely limited. I never could
get the hang of foreign languages because I can't remember vocabulary.
So, I stick by my preference not to rewrite all the existing Perl
scripts as Python, except in cases where I am not needed for their
future maintenance. I understand that it is important to move away
from C-shell, and that's fine. Unfortunately, my ability to fix
anything more than the way the Radiance tools get called in Python is
currently zero, and looking at your new scripts, I don't see that
changing anytime soon.
Also, I wish I had some test cases for these scripts, but I was never
really good about that. I generally wrote something when I needed it
or had an example ready, but I didn't have the foresight to keep those
examples around, so I'm not much help there. Sorry!
-Greg

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 2:21:12 PM PDT
Greg, someone of your capacity will be fluent in the Python syntax within
an hour, the object and exception system in a day, and the most elementary
parts of the library within a few days (the included library is so huge
that even experienced pythonistas will keep searching the documentation
for more arcane modules).
Python is "the language thet doesn't get in the way", and not another Perl.
You will very quickly have less problems debugging a Python program by
someone else, compared to a Perl program you have written yourself.
While I definitively understand your reluctance, I also think that in this
specific case you will find it to be unjustified.
And if you should still run into trouble, there are enough Radiance users
out there who are already very fluent and can help out.
So now we need a few more good conversion candidates with test cases.
Do you by chance still have any of the test cases you used to verify
the existing scripts when you created them?
-schorsch
Am 2016-03-21 20:44, schrieb Gregory J. Ward:

There is the downside that I don't know Python at all, and learning
yet another object-oriented language with completely different syntax
isn't high on my list of priorities. That said, if we can get past
the support issues on various platforms, I have no problem with
Schorsch and others making contributions they wish to support on an
ongoing basis, or ones that are unlikely to require support.
For this reason, I don't have much enthusiasm for converting something
as complex as genBSDF to Python, where I couldn't understand or fix
any problems that arise in future.
Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 9:02:03 AM PDT
Hi again!
I have converted some of the original Radiance shell scripts into Python.
https://github.com/gmischler/PyRad
The examples so far are exact drop-in replacements of the original csh
or Perl versions, but with some extra functionality and benefits.
* usage instructions (-H)
* progress report (-V)
* dry-run mode (-N)
* detailed error diagnostics
* compatible with Python 2.7 and Python 3.x
* self contained (all functionality can be combined in one file)
* truly cross-platform (no dependencies other than Python and Radiance)
* direct process management (no intermediate shell calls)
* immune to whitespace in file names
* tamper-proof use of temporary files
* instrumented for building a single-file *.exe with pyinstaller
The current selection is still small, the examples were chosen for
varying reasons:
* falsecolor.py
This one has been sitting on my disk (in much less refined form) for
many years. Now I've updated it to using color palettes and to satisfy
all the points above.
* phisto.py
* rlux.py
* pveil.py
Those three became test candidates because they are simple and have
a straightforward command line.
I'm looking for ideas (and contributions) on where to continue next.
Good candidates are scripts that are commonly used.
It is also very helpful if a script includes documentation about what
it's actually supposed to do. Ideally with a set of test data to
verify that it really does that.
Actually, a solid set of test cases for the current collection would
be very helpful too.
Some of the csh/Perl scripts present a challenge, because they have
rather unconventional command lines. In those cases, we might want to
consider changing the interface to something more regular, provided
this is possible.
Not all of the existing scripts are really worth the effort.
The Python versions with the extra functionality are definitively not
as simple as the originals. Flexibility and safety has its price.
On the other hand, they will definitively be *much* easier to maintain.
Many of the current scripts (csh *and* Perl) blindly assume the
existence of a unix type shell, a number of other posix tools
(grep/awk/sed/etc.), and they often fail with spaces in file and
directory names. Fixing this would introduce additional overhead
in any language.
Why Python?
For developers, it is simply one of the most productive tools around.
Python has grown into one of the most popular languages just by its
practical merits, without any corporate backing, and without a very
strong web appeal.
Most Radiance users will already have it installed, no matter the
platform.
On unix, scripts can be invoked by "#!" (like any other).
Any script can be "compiled" into a standalone executable file.
This is important on Windows, because invoking scripts (Python,
*.bat, or otherwise) from within programs is a real hassle there.
In fact, it ended up being the simplest way to get winimage to
perform falsecolor analysis.
(This could also be done with Perl, but...)
I expect Python to play an increasing role in Radiance development in
the future, with or without my own involvement. So we might just as
well embrace it.
I would like to suggest adding Python versions of the most commonly
used scripts to the distribution. There are several possible
configurations how this could be done, so we'd have to discuss a
number of technical details first. And yes, verification before
inclusion would be an important step.
Opinions?
-schorsch

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

[Greg_Ward]

Getting old? That, I am!

Seriously, though, what's up with all the double-subscripts on string arrays? Seems you always need string[0][0] to access a word, when I would expect just one subscript unless you want a character. And I have absolutely no clue how the quoted line extracts the final file component from a path, assuming that's its purpose. Python seems to introduce a whole new set of conventions, which if my mind weren't already polluted by the conventions of half a dozen other languages, probably wouldn't give me so much trouble.

The only real benefit I see to your recommendation, other than having just one language to deal with, is that we don't have to mess with different quoting conventions between Windows and Unix shell interpreters. That does simplify things a bit, but we still need to change options around because Windows doesn't handle binary data transfer reliably. So, piped commands still are not 100% portable even in Python. We'd still have to switch between data format (-f*) command options on the two platforms, or suffer significant performance penalties on Unix.

Cheers,
-Greg

···

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 5:21:45 PM PDT

If that exceeds your syntax input queue, then you're getting old!

Am 2016-03-22 00:52, schrieb Gregory J. Ward:

All I can say is:
  SHORTPROGN = os.path.splitext(os.path.split(sys.argv[0])[1])[0]

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 4:22:47 PM PDT
You're arguing with some of the most syntactitcally complex aspects
of current programming languages here. (STL?!?)
In contrast, Pythons syntax was specifically designed to be easy to
understand and use (there's a lot of research into that).
Maybe you should just invest an hour and play through the tutorial
https://docs.python.org/3/tutorial/ (also in the downloaded docs)
Then you may see firsthand that Python is really different from
all the horrible things you've already seen...
If you can't get your head wrapped around object oriented ideas,
Python won't force them onto you (other than Java). But if you want
to use them, they're much simpler to implement in Python.
Python is "the language that doesn't get in the way".
-schorsch
Am 2016-03-21 22:55, schrieb Gregory J. Ward:

Hmmm... Well, I may be a little thicker with respect to learning new
languages than you give me credit for. Lately, I've been trying to
pick up Java for one of my client projects and having a lot of
trouble, despite (or because of?) its passing similarity to C++. Perl
is relatively easy for me precisely because it doesn't have all the
object-oriented stuff or extensive libraries. I always avoided the
C++ STL because I never could understand what they wanted me to do
with it. It's less a matter of language philosophy and more a matter
of how much vocabulary/syntax one needs to master, because my mental
capacity for "miscellaneous stuff" is severely limited. I never could
get the hang of foreign languages because I can't remember vocabulary.
So, I stick by my preference not to rewrite all the existing Perl
scripts as Python, except in cases where I am not needed for their
future maintenance. I understand that it is important to move away
from C-shell, and that's fine. Unfortunately, my ability to fix
anything more than the way the Radiance tools get called in Python is
currently zero, and looking at your new scripts, I don't see that
changing anytime soon.
Also, I wish I had some test cases for these scripts, but I was never
really good about that. I generally wrote something when I needed it
or had an example ready, but I didn't have the foresight to keep those
examples around, so I'm not much help there. Sorry!
-Greg

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 2:21:12 PM PDT
Greg, someone of your capacity will be fluent in the Python syntax within
an hour, the object and exception system in a day, and the most elementary
parts of the library within a few days (the included library is so huge
that even experienced pythonistas will keep searching the documentation
for more arcane modules).
Python is "the language thet doesn't get in the way", and not another Perl.
You will very quickly have less problems debugging a Python program by
someone else, compared to a Perl program you have written yourself.
While I definitively understand your reluctance, I also think that in this
specific case you will find it to be unjustified.
And if you should still run into trouble, there are enough Radiance users
out there who are already very fluent and can help out.
So now we need a few more good conversion candidates with test cases.
Do you by chance still have any of the test cases you used to verify
the existing scripts when you created them?
-schorsch
Am 2016-03-21 20:44, schrieb Gregory J. Ward:

There is the downside that I don't know Python at all, and learning
yet another object-oriented language with completely different syntax
isn't high on my list of priorities. That said, if we can get past
the support issues on various platforms, I have no problem with
Schorsch and others making contributions they wish to support on an
ongoing basis, or ones that are unlikely to require support.
For this reason, I don't have much enthusiasm for converting something
as complex as genBSDF to Python, where I couldn't understand or fix
any problems that arise in future.
Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 9:02:03 AM PDT
Hi again!
I have converted some of the original Radiance shell scripts into Python.
https://github.com/gmischler/PyRad
The examples so far are exact drop-in replacements of the original csh
or Perl versions, but with some extra functionality and benefits.
* usage instructions (-H)
* progress report (-V)
* dry-run mode (-N)
* detailed error diagnostics
* compatible with Python 2.7 and Python 3.x
* self contained (all functionality can be combined in one file)
* truly cross-platform (no dependencies other than Python and Radiance)
* direct process management (no intermediate shell calls)
* immune to whitespace in file names
* tamper-proof use of temporary files
* instrumented for building a single-file *.exe with pyinstaller
The current selection is still small, the examples were chosen for
varying reasons:
* falsecolor.py
This one has been sitting on my disk (in much less refined form) for
many years. Now I've updated it to using color palettes and to satisfy
all the points above.
* phisto.py
* rlux.py
* pveil.py
Those three became test candidates because they are simple and have
a straightforward command line.
I'm looking for ideas (and contributions) on where to continue next.
Good candidates are scripts that are commonly used.
It is also very helpful if a script includes documentation about what
it's actually supposed to do. Ideally with a set of test data to
verify that it really does that.
Actually, a solid set of test cases for the current collection would
be very helpful too.
Some of the csh/Perl scripts present a challenge, because they have
rather unconventional command lines. In those cases, we might want to
consider changing the interface to something more regular, provided
this is possible.
Not all of the existing scripts are really worth the effort.
The Python versions with the extra functionality are definitively not
as simple as the originals. Flexibility and safety has its price.
On the other hand, they will definitively be *much* easier to maintain.
Many of the current scripts (csh *and* Perl) blindly assume the
existence of a unix type shell, a number of other posix tools
(grep/awk/sed/etc.), and they often fail with spaces in file and
directory names. Fixing this would introduce additional overhead
in any language.
Why Python?
For developers, it is simply one of the most productive tools around.
Python has grown into one of the most popular languages just by its
practical merits, without any corporate backing, and without a very
strong web appeal.
Most Radiance users will already have it installed, no matter the
platform.
On unix, scripts can be invoked by "#!" (like any other).
Any script can be "compiled" into a standalone executable file.
This is important on Windows, because invoking scripts (Python,
*.bat, or otherwise) from within programs is a real hassle there.
In fact, it ended up being the simplest way to get winimage to
perform falsecolor analysis.
(This could also be done with Perl, but...)
I expect Python to play an increasing role in Radiance development in
the future, with or without my own involvement. So we might just as
well embrace it.
I would like to suggest adding Python versions of the most commonly
used scripts to the distribution. There are several possible
configurations how this could be done, so we'd have to discuss a
number of technical details first. And yes, verification before
inclusion would be an important step.
Opinions?
-schorsch

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

[Randolph_Fritz4]

The problem that code solves is finding the name of the invoked command and
getting rid of the Windows .exe extension. I'd write it a bit differently:

  from os.path import basename, splitext
  ...
  progname = splitext(basename(sys.argv[0]))[0]

  (or, at length)
  progfile = basename(sys.argv[0])
  progname = splitext(progfile)[0]

On the other hand, it probably ought to be encapsulated somewhere in a
function or class, so that one does not have to look at it too much.

The binary EOF thing was a problem of the old FAT filesystem, which
operated in blocks, and EOF was an actual character in the file. It is
still present in NTFS, then? Say, what?

[Georg_Mischler]

Getting old? That, I am!

Hehe, so am I!

Seriously, though, what's up with all the double-subscripts on string
arrays? Seems you always need string[0][0] to access a word, when I
would expect just one subscript unless you want a character.

Where did you see a double-subscript?

It's essentially the equivalent of fixargv0() (two dozen lines of C).
But since it consists of just two nested library calls, there's no
point in turning it into an extra function.

And I
have absolutely no clue how the quoted line extracts the final file
component from a path, assuming that's its purpose. Python seems to
introduce a whole new set of conventions, which if my mind weren't
already polluted by the conventions of half a dozen other languages,
probably wouldn't give me so much trouble.

If every language used the same concepts and conventions, there'd
be little point in having more than one of them, would there?

Those are rather straightforward functions from the library module
"os.path", accessing an attribute (in this case a list of strings)
of the module "sys".
Once you have familiarized youself with the basics of how to invoke
library functions in Python, It's easy to guess what they do just by
looking at their names.

The only real benefit I see to your recommendation, other than having
just one language to deal with, is that we don't have to mess with
different quoting conventions between Windows and Unix shell
interpreters.

The problem here is that Radiance uses the shell (via posix system()
and popen()) to invoke subprocesses. In a multi-platform environment,
those functions should be avoided to begin with, but that would be a
lot of work to change now in Radiance.

I have written win_popen.c and win_process.c many years ago to
circumvent (not solve!) the problem in Radiance itself.

In Python, using os.system() and os.popen() would result in the same
problems. That's why I'm using the "subprocess" library module, which
invokes processes directly and encapsulates the platform differences.

One of the consequences is that pipes aren't chained automatically,
so we need some extra code to handle those (same as win_popen() does).
But that's a price we should be willing to pay in any language we use.
This functionality is tucked away in the pyradlib/pyrad_proc.py module,
and - once finalized - should never need to be touched again.

That does simplify things a bit, but we still need to
change options around because Windows doesn't handle binary data
transfer reliably. So, piped commands still are not 100% portable
even in Python.

Windows can handle binary data transfers just fine.
Or are you talking about "\r\n"?
That is a rather minor problem in Python, since we need to
distinguish between binary and text data streams anyway.
You don't want your binary data converted to Unicode, do you?

We'd still have to switch between data format (-f*)
command options on the two platforms, or suffer significant
performance penalties on Unix.

Sorry, not sure what you're talking about there.

Cheers
-schorsch

···

Am 2016-03-22 01:34, schrieb Gregory J. Ward:

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 5:21:45 PM PDT

If that exceeds your syntax input queue, then you're getting old!

Am 2016-03-22 00:52, schrieb Gregory J. Ward:

All I can say is:
  SHORTPROGN = os.path.splitext(os.path.split(sys.argv[0])[1])[0]

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 4:22:47 PM PDT
You're arguing with some of the most syntactitcally complex aspects
of current programming languages here. (STL?!?)
In contrast, Pythons syntax was specifically designed to be easy to
understand and use (there's a lot of research into that).
Maybe you should just invest an hour and play through the tutorial
https://docs.python.org/3/tutorial/ (also in the downloaded docs)
Then you may see firsthand that Python is really different from
all the horrible things you've already seen...
If you can't get your head wrapped around object oriented ideas,
Python won't force them onto you (other than Java). But if you want
to use them, they're much simpler to implement in Python.
Python is "the language that doesn't get in the way".
-schorsch
Am 2016-03-21 22:55, schrieb Gregory J. Ward:

Hmmm... Well, I may be a little thicker with respect to learning new
languages than you give me credit for. Lately, I've been trying to
pick up Java for one of my client projects and having a lot of
trouble, despite (or because of?) its passing similarity to C++. Perl
is relatively easy for me precisely because it doesn't have all the
object-oriented stuff or extensive libraries. I always avoided the
C++ STL because I never could understand what they wanted me to do
with it. It's less a matter of language philosophy and more a matter
of how much vocabulary/syntax one needs to master, because my mental
capacity for "miscellaneous stuff" is severely limited. I never could
get the hang of foreign languages because I can't remember vocabulary.
So, I stick by my preference not to rewrite all the existing Perl
scripts as Python, except in cases where I am not needed for their
future maintenance. I understand that it is important to move away
from C-shell, and that's fine. Unfortunately, my ability to fix
anything more than the way the Radiance tools get called in Python is
currently zero, and looking at your new scripts, I don't see that
changing anytime soon.
Also, I wish I had some test cases for these scripts, but I was never
really good about that. I generally wrote something when I needed it
or had an example ready, but I didn't have the foresight to keep those
examples around, so I'm not much help there. Sorry!
-Greg

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 2:21:12 PM PDT
Greg, someone of your capacity will be fluent in the Python syntax within
an hour, the object and exception system in a day, and the most elementary
parts of the library within a few days (the included library is so huge
that even experienced pythonistas will keep searching the documentation
for more arcane modules).
Python is "the language thet doesn't get in the way", and not another Perl.
You will very quickly have less problems debugging a Python program by
someone else, compared to a Perl program you have written yourself.
While I definitively understand your reluctance, I also think that in this
specific case you will find it to be unjustified.
And if you should still run into trouble, there are enough Radiance users
out there who are already very fluent and can help out.
So now we need a few more good conversion candidates with test cases.
Do you by chance still have any of the test cases you used to verify
the existing scripts when you created them?
-schorsch
Am 2016-03-21 20:44, schrieb Gregory J. Ward:

There is the downside that I don't know Python at all, and learning
yet another object-oriented language with completely different syntax
isn't high on my list of priorities. That said, if we can get past
the support issues on various platforms, I have no problem with
Schorsch and others making contributions they wish to support on an
ongoing basis, or ones that are unlikely to require support.
For this reason, I don't have much enthusiasm for converting something
as complex as genBSDF to Python, where I couldn't understand or fix
any problems that arise in future.
Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Python scripts for Radiance
Date: March 21, 2016 9:02:03 AM PDT
Hi again!
I have converted some of the original Radiance shell scripts into Python.
https://github.com/gmischler/PyRad
The examples so far are exact drop-in replacements of the original csh
or Perl versions, but with some extra functionality and benefits.
* usage instructions (-H)
* progress report (-V)
* dry-run mode (-N)
* detailed error diagnostics
* compatible with Python 2.7 and Python 3.x
* self contained (all functionality can be combined in one file)
* truly cross-platform (no dependencies other than Python and Radiance)
* direct process management (no intermediate shell calls)
* immune to whitespace in file names
* tamper-proof use of temporary files
* instrumented for building a single-file *.exe with pyinstaller
The current selection is still small, the examples were chosen for
varying reasons:
* falsecolor.py
This one has been sitting on my disk (in much less refined form) for
many years. Now I've updated it to using color palettes and to satisfy
all the points above.
* phisto.py
* rlux.py
* pveil.py
Those three became test candidates because they are simple and have
a straightforward command line.
I'm looking for ideas (and contributions) on where to continue next.
Good candidates are scripts that are commonly used.
It is also very helpful if a script includes documentation about what
it's actually supposed to do. Ideally with a set of test data to
verify that it really does that.
Actually, a solid set of test cases for the current collection would
be very helpful too.
Some of the csh/Perl scripts present a challenge, because they have
rather unconventional command lines. In those cases, we might want to
consider changing the interface to something more regular, provided
this is possible.
Not all of the existing scripts are really worth the effort.
The Python versions with the extra functionality are definitively not
as simple as the originals. Flexibility and safety has its price.
On the other hand, they will definitively be *much* easier to maintain.
Many of the current scripts (csh *and* Perl) blindly assume the
existence of a unix type shell, a number of other posix tools
(grep/awk/sed/etc.), and they often fail with spaces in file and
directory names. Fixing this would introduce additional overhead
in any language.
Why Python?
For developers, it is simply one of the most productive tools around.
Python has grown into one of the most popular languages just by its
practical merits, without any corporate backing, and without a very
strong web appeal.
Most Radiance users will already have it installed, no matter the
platform.
On unix, scripts can be invoked by "#!" (like any other).
Any script can be "compiled" into a standalone executable file.
This is important on Windows, because invoking scripts (Python,
*.bat, or otherwise) from within programs is a real hassle there.
In fact, it ended up being the simplest way to get winimage to
perform falsecolor analysis.
(This could also be done with Perl, but...)
I expect Python to play an increasing role in Radiance development in
the future, with or without my own involvement. So we might just as
well embrace it.
I would like to suggest adding Python versions of the most commonly
used scripts to the distribution. There are several possible
configurations how this could be done, so we'd have to discuss a
number of technical details first. And yes, verification before
inclusion would be an important step.
Opinions?
-schorsch

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

[Greg_Ward]

Removing some stuff to keep things from getting too drawn-out...

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Python scripts for Radiance
Date: March 22, 2016 4:49:39 AM PDT

...
Where did you see a double-subscript?

I think it's when you're calling your parser library, which must be putting arguments into 2-D arrays.

It's essentially the equivalent of fixargv0() (two dozen lines of C).
But since it consists of just two nested library calls, there's no
point in turning it into an extra function.

If every language used the same concepts and conventions, there'd
be little point in having more than one of them, would there?

Those are rather straightforward functions from the library module
"os.path", accessing an attribute (in this case a list of strings)
of the module "sys".
Once you have familiarized youself with the basics of how to invoke
library functions in Python, It's easy to guess what they do just by
looking at their names.

Well, it's still not obvious to me, even after Randoph's explanation (which used different calls). In any case, I was only trying to make the point that Python isn't transparent, either.

Thinking on it some more, the main issue I have with Python is probably the object-oriented structure, which moves it even further from a command-line interpreter. For me, the main benefit of using a scripting language is that it is close to the command-line, which is where Radiance (mostly) lives. If you introduce too much structure, you're getting back to something resembling a C program, and you may as well just write it that way, instead.

Perl looks a lot like traditional interpreter shells with the added benefit of more useful built-in commands and expression evaluation. You can open a Perl script and read through it like you're reading a sequence of commands. User-defined functions have a bare-bones call structure and don't have to be defined before they're used, so they don't interrupt the flow as you read through the code. Scripting languages need to be easy to write and easy to read to be useful in my opinion. They don't have to be beautiful.

Also, relying heavily on add-on libraries comes at a cost, which is expanded vocabulary one must learn. We get by in Perl with just one library for making temp files, I think, and that was added to avoid some of the system incompatibilities with Windows and is only called in a couple of places.

The only real benefit I see to your recommendation, other than having
just one language to deal with, is that we don't have to mess with
different quoting conventions between Windows and Unix shell
interpreters.

The problem here is that Radiance uses the shell (via posix system()
and popen()) to invoke subprocesses. In a multi-platform environment,
those functions should be avoided to begin with, but that would be a
lot of work to change now in Radiance.

I have written win_popen.c and win_process.c many years ago to
circumvent (not solve!) the problem in Radiance itself.

In Python, using os.system() and os.popen() would result in the same
problems. That's why I'm using the "subprocess" library module, which
invokes processes directly and encapsulates the platform differences.

One of the consequences is that pipes aren't chained automatically,
so we need some extra code to handle those (same as win_popen() does).
But that's a price we should be willing to pay in any language we use.
This functionality is tucked away in the pyradlib/pyrad_proc.py module,
and - once finalized - should never need to be touched again.

We chain up to 4 commands in genBSDF, which I guess will translate to call_four() in your library?

That does simplify things a bit, but we still need to
change options around because Windows doesn't handle binary data
transfer reliably. So, piped commands still are not 100% portable
even in Python.

Windows can handle binary data transfers just fine.
Or are you talking about "\r\n"?
That is a rather minor problem in Python, since we need to
distinguish between binary and text data streams anyway.
You don't want your binary data converted to Unicode, do you?

We'd still have to switch between data format (-f*)
command options on the two platforms, or suffer significant
performance penalties on Unix.

Sorry, not sure what you're talking about there.

Well, we may need to devise some tests to be sure this is still a problem, but in the past, Windows would deliver binary files in 128-byte chunks, meaning that the last chunk might have garbage at the end of it that was not actually produced by the program that sent it. So long as the receiving program knows exactly how much data to expect, which is frequently the case, there is no problem. However, if the receiving program is counting bytes to see how much data it gets (like rcalc, total, etc.) then it screws up the results, which is why we've been sticking with ASCII data in Windows despite the horrendous overhead translating between ASCII and IEEE floating-point.

Cheers,
-Greg

···

Am 2016-03-22 01:34, schrieb Gregory J. Ward:

[Guglielmetti_Robert]

This is getting good...

Thinking on it some more, the main issue I have with Python is probably
the object-oriented structure, which moves it even further from a
command-line interpreter. For me, the main benefit of using a scripting
language is that it is close to the command-line, which is where Radiance
(mostly) lives. If you introduce too much structure, you're getting back
to something resembling a C program, and you may as well just write it
that way, instead.

Perl looks a lot like traditional interpreter shells with the added
benefit of more useful built-in commands and expression evaluation. You
can open a Perl script and read through it like you're reading a sequence
of commands. User-defined functions have a bare-bones call structure and
don't have to be defined before they're used, so they don't interrupt the
flow as you read through the code. Scripting languages need to be easy
to write and easy to read to be useful in my opinion. They don't have to
be beautiful.

Also, relying heavily on add-on libraries comes at a cost, which is
expanded vocabulary one must learn. We get by in Perl with just one
library for making temp files, I think, and that was added to avoid some
of the system incompatibilities with Windows and is only called in a
couple of places.

Eh, I respectfully disagree, here. Languages like Python and Ruby are
making it easy for meatheads like me to write functional cross-platform
programs that can leverage Radiance tools well, and offer users niceties
like command line help, threading, queuing, etc. One could write these
with minimal library support and blow off making functions where they make
sense and leave one with a very linear, readable (and maintainable)
program. On the other hand, wrapping a few redundant bits into a function
here and there makes it cleaner, easier to maintain, and IMO does not come
anywhere close to the price of admission of writing the same shit in C or
C++.(!)

Well, we may need to devise some tests to be sure this is still a
problem, but in the past, Windows would deliver binary files in 128-byte
chunks, meaning that the last chunk might have garbage at the end of it
that was not actually produced by the program that sent it. So long as
the receiving program knows exactly how much data to expect, which is
frequently the case, there is no problem. However, if the receiving
program is counting bytes to see how much data it gets (like rcalc,
total, etc.) then it screws up the results, which is why we've been
sticking with ASCII data in Windows despite the horrendous overhead
translating between ASCII and IEEE floating-point.

This was still a problem last year when I was writing the
Radiance-OpenStudio stuff, and is a major roadblock for doing large scale
analysis with Radiance on Windows, I'm finding. =(

···

On 3/22/16, 10:02 AM, "Gregory J. Ward" <[email protected]> wrote:

[Greg_Ward]

Real quick:

From: "Guglielmetti, Robert" <[email protected]>
Date: March 22, 2016 9:37:46 AM PDT

Eh, I respectfully disagree, here. Languages like Python and Ruby are
making it easy for meatheads like me to write functional cross-platform
programs that can leverage Radiance tools well, and offer users niceties
like command line help, threading, queuing, etc. One could write these
with minimal library support and blow off making functions where they make
sense and leave one with a very linear, readable (and maintainable)
program. On the other hand, wrapping a few redundant bits into a function
here and there makes it cleaner, easier to maintain, and IMO does not come
anywhere close to the price of admission of writing the same shit in C or
C++.(!)

I wasn't arguing against defining your own functions or encapsulation -- just heavy reliance on add-on libraries. The former just keeps the code neat, moving repeated or complicated calls to another part of the script. The latter means you have to go learn about some library you never heard of and study it to figure out what the script is even doing. Arguments about obviousness notwithstanding, you can't debug a program you don't fully understand.

-G

[Randolph_Fritz4]

I don’t think it’s as awful as that; Python is a widely-known, widely-used, and well-documented language and freely available. I worry more about Perl, because it is so easy to create write-only code in Perl and this becomes a maintenance problem.

On the other hand some Unix commands are becoming obsolete. I use awk and csh and wonder how long they will last. Like languages, computing environments change over time.

The justification for the various interpretive languages is development speed and (mostly) ease of maintenance; one can probably write most things in Python in 1/10th the time it takes to write them in C, and with modern computers so fast, you may never actually have to write the code in C, or at least put that step off for some time. If your first version is adequate, why fiddle with it? There is some effort at bridging the productivity gap between compiled and interpreted languages. Unfortunately that work has not so far reached scientific and engineering computing. We’re still using FORTRAN for some things!

Randolph

···

On Mar 22, 2016, at 9:48 AM, Gregory J. Ward <[email protected]> wrote:

Real quick:

From: "Guglielmetti, Robert" <[email protected]>
Date: March 22, 2016 9:37:46 AM PDT

Eh, I respectfully disagree, here. Languages like Python and Ruby are
making it easy for meatheads like me to write functional cross-platform
programs that can leverage Radiance tools well, and offer users niceties
like command line help, threading, queuing, etc. One could write these
with minimal library support and blow off making functions where they make
sense and leave one with a very linear, readable (and maintainable)
program. On the other hand, wrapping a few redundant bits into a function
here and there makes it cleaner, easier to maintain, and IMO does not come
anywhere close to the price of admission of writing the same shit in C or
C++.(!)

I wasn't arguing against defining your own functions or encapsulation -- just heavy reliance on add-on libraries. The former just keeps the code neat, moving repeated or complicated calls to another part of the script. The latter means you have to go learn about some library you never heard of and study it to figure out what the script is even doing. Arguments about obviousness notwithstanding, you can't debug a program you don't fully understand.

-G
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

[Georg_Mischler]

Well, it's still not obvious to me, even after Randoph's explanation
(which used different calls). In any case, I was only trying to make
the point that Python isn't transparent, either.

An unknown language is never immediately transparent without some
minimal learning effort. But that's not necessarily because it's
difficult - just because it's new.

Thinking on it some more, the main issue I have with Python is
probably the object-oriented structure, which moves it even further
from a command-line interpreter. For me, the main benefit of using a
scripting language is that it is close to the command-line, which is
where Radiance (mostly) lives. If you introduce too much structure,
you're getting back to something resembling a C program, and you may
as well just write it that way, instead.

There are (at least) two different classes of "scripts" in Radiance.
Some are indeed little more than a listing of a few commands, and
in a few cases it looks like they were one-off solutions to a very
specific problem. Most people will never use those, or they might
create their own versions. It may or may not be worth to convert
them, and in some cases the Python version may actually become a
literal translation without any added structure.

The other class are programs like falsecolor or genBSDF, which are
far beyond that "script" stage. Those are "real" programs in the sense
that they solve tasks that most people will be confronted with
regularly. This makes them unlikely to change very significantly over
time, other than to add features. In those cases, the effort is
clearly justified to design an object oriented structure and add all
the bells and whistles most users expect from a complete tool.

You seem to think that object orientation will necessarily make a program
inflexible. Well, for Java and C++, this is indeed usually the case.
But it doesn't have to be like that. A well crafted object oriented
design will make adding features easier, not harder. And Python is one
of the rare languages, where changing the code is actually fun, and
not something to be scared of.

This ease of maintenance is also one of the reasons why those things
should rather *not* be converted to C. There's simply no need to do that,
as long as we can delegate the number crunching to other tools.

Perl looks a lot like traditional interpreter shells with the added
benefit of more useful built-in commands and expression evaluation.
You can open a Perl script and read through it like you're reading a
sequence of commands. User-defined functions have a bare-bones call
structure and don't have to be defined before they're used, so they
don't interrupt the flow as you read through the code.

If you look at Python, you'll find that all that is (or can be) the
case there as well, just without the uglyness.

Scripting languages need to be easy to write and easy to read to be
useful in my opinion.

But you're still full of praise for Perl...?

Also, relying heavily on add-on libraries comes at a cost, which is
expanded vocabulary one must learn.

Libraries coming included with the language are not "add-on".
We won't get any bonus points for reinventing the wheel, or for
dragging stuff around instead of wheeling it.

We chain up to 4 commands in genBSDF, which I guess will translate to
call_four() in your library?

We're going to have a call_many() then, which will accept and chain an
arbitrary number of commands. Win_popen() already does that.

We'd still have to switch between data format (-f*)
command options on the two platforms, or suffer significant
performance penalties on Unix.

Sorry, not sure what you're talking about there.

Well, we may need to devise some tests to be sure this is still a
problem, but in the past, Windows would deliver binary files in
128-byte chunks, meaning that the last chunk might have garbage at the
end of it that was not actually produced by the program that sent it.

That sounds like a severely broken implementation. I can't possibly
imagine this still to be the case. If there's a test case, I'll check
it out.

Cheers
-schorsch

···

Am 2016-03-22 01:34, schrieb Gregory J. Ward:

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

[Randolph_Fritz4]

Greg:
​

Well, we may need to devise some tests to be sure this is still a
problem, but in the past, Windows would deliver binary files in
128-byte chunks, meaning that the last chunk might have garbage at the
end of it that was not actually produced by the program that sent it.

Schorsch

That sounds like a severely broken implementation. I can't possibly
imagine this still to be the case. If there's a test case, I'll check
it out.

It's a hang-over from MS-DOS and its FAT filesystem, which measured files
in blocks rather than bytes. I'd be surprised if Windows NTFS has the
problem, *but* memory sticks still use a FAT filesystem, so the problem may
emerge when transporting files on a memory stick. That's a case to test.

Greg, I once tried writing all my project scripts in Python. Ultimately I
got sick of it and reverted to csh. But for the a-bit-more-than-a-script
problems that Schorsh is talking about, Python is an enormous help, making
the development process faster and less error-prone. Compared to any shell,
Python makes it easier to write correct code. Compared to C, python is far
more concise, making coding much faster, which is why we don't just use C
instead. And, truly, it does not impose the formal requirements that Java
or C++ does. I wish you would give it another look before deciding it's
hopeless.

And back to work with me.

Randolph

[Greg_Ward]

From: Georg Mischler <[email protected]>
Date: March 22, 2016 12:30:46 PM PDT
...

Thinking on it some more, the main issue I have with Python is
probably the object-oriented structure, which moves it even further
from a command-line interpreter. For me, the main benefit of using a
scripting language is that it is close to the command-line, which is
where Radiance (mostly) lives. If you introduce too much structure,
you're getting back to something resembling a C program, and you may
as well just write it that way, instead.

There are (at least) two different classes of "scripts" in Radiance.
Some are indeed little more than a listing of a few commands, and
in a few cases it looks like they were one-off solutions to a very
specific problem. Most people will never use those, or they might
create their own versions. It may or may not be worth to convert
them, and in some cases the Python version may actually become a
literal translation without any added structure.

OK, I suppose I would have to see an example of that, preferably something that wasn't organized around a class. One of the things I have always disliked about C++ is how you have to dig around in the headers to figure out what the heck the code is doing. Python at least keeps it together, but it's still a mess in the sense that the code layout has little to do with control flow. It's an extra hurdle to understanding I could do without.

There's still the issue of all the supporting libraries, their many classes and associated methods.

The other class are programs like falsecolor or genBSDF, which are
far beyond that "script" stage. Those are "real" programs in the sense
that they solve tasks that most people will be confronted with
regularly. This makes them unlikely to change very significantly over
time, other than to add features. In those cases, the effort is
clearly justified to design an object oriented structure and add all
the bells and whistles most users expect from a complete tool.

Never mind that I just rewrote genBSDF almost from scratch last year when I introduced rfluxmtx and wrapBSDF with color support, which simplified the code substantially (and required numerous changes in structure). I was hoping not to have to do that again, of course....

You seem to think that object orientation will necessarily make a program
inflexible. Well, for Java and C++, this is indeed usually the case.
But it doesn't have to be like that. A well crafted object oriented
design will make adding features easier, not harder. And Python is one
of the rare languages, where changing the code is actually fun, and
not something to be scared of.

This ease of maintenance is also one of the reasons why those things
should rather *not* be converted to C. There's simply no need to do that,
as long as we can delegate the number crunching to other tools.

Certain things are definitely easier in a scripting language, or they wouldn't be useful. Being able to manipulate strings and build command lines are the most important facilities. Having some ability to do math and store arrays are also valuable features. Perl and Python are both superior to the C-shell in that respect, so I agree with you about the importance of having a decent language for more sophisticated tools. However, I don't see how Python is less work than Perl given the examples I've seen. Why not Ruby? Why not any of the other myriad languages out there? You have your favorite; I have none. I simply went with something that was familiar and supported, and don't feel like changing canoes midstream as the expression goes.

Perl looks a lot like traditional interpreter shells with the added
benefit of more useful built-in commands and expression evaluation.
You can open a Perl script and read through it like you're reading a
sequence of commands. User-defined functions have a bare-bones call
structure and don't have to be defined before they're used, so they
don't interrupt the flow as you read through the code.

If you look at Python, you'll find that all that is (or can be) the
case there as well, just without the uglyness.

As I said, I would have to see a simple example. Your rlux.py ended up being a bit more complex than its C-shell progenitor... As for ugliness, I don't really see the differences you do. I have employed languages like TCL, which I do consider write-only (to use Randoph's term), but Perl is OK for me.

Scripting languages need to be easy to write and easy to read to be
useful in my opinion.

But you're still full of praise for Perl...?

I do find Perl easy to read compared to Python, mostly because I don't have to jump around the class methods or read up on the add-on libraries. There are plenty of functions in Perl, no doubt about that, but they aren't such a growing concern.

Also, relying heavily on add-on libraries comes at a cost, which is
expanded vocabulary one must learn.

Libraries coming included with the language are not "add-on".
We won't get any bonus points for reinventing the wheel, or for
dragging stuff around instead of wheeling it.

I'm not saying we need to reinvent the wheel every time, but we could do without so many wheels. Perhaps it's just a matter of restraint and paring add-on libraries to a minimum. I don't know.

We chain up to 4 commands in genBSDF, which I guess will translate to
call_four() in your library?

We're going to have a call_many() then, which will accept and chain an
arbitrary number of commands. Win_popen() already does that.

OK, I guess that would work.

We'd still have to switch between data format (-f*)
command options on the two platforms, or suffer significant
performance penalties on Unix.

Sorry, not sure what you're talking about there.

Well, we may need to devise some tests to be sure this is still a
problem, but in the past, Windows would deliver binary files in
128-byte chunks, meaning that the last chunk might have garbage at the
end of it that was not actually produced by the program that sent it.

That sounds like a severely broken implementation. I can't possibly
imagine this still to be the case. If there's a test case, I'll check
it out.

I don't own a Windows box, so it's difficult for me to produce test cases. I only hear complaints from people about certain commands not behaving with binary data on Windows, even when it doesn't go into an intermediate file. In other words, piping the binary output of one command into another still screws up. Does Windows create a temporary file when it does this? Maybe if it's on a FAT filesystem (as Randolph mentioned), this is the source of the problem. It would be nice to track this down. Although I don't have a ready solution, it would be good to at least determine the parameters of the problem. (Radiance's binary files are immune: octrees, HDR pictures, triangle meshes, even binary matrix data -- it's just the raw IEEE floats & doubles that usually mess up.)

Cheers,
-Greg

[Randolph_Fritz4]

I don't think Perl is necessarily write-only, but it is easy to produce
write-only code in it.

"Although I don't have a ready solution, it would be good to at least
determine the parameters of the problem."

Does anyone have an example? When I get a bit more time, I could look into
it.

···

--
Randolph M. Fritz, Lighting Design and Simulation
+1 206 659-8617 || [email protected]

On Tue, Mar 22, 2016 at 4:04 PM, Gregory J. Ward <[email protected]> wrote:

> From: Georg Mischler <[email protected]>
> Date: March 22, 2016 12:30:46 PM PDT
> ...
>> Thinking on it some more, the main issue I have with Python is
>> probably the object-oriented structure, which moves it even further
>> from a command-line interpreter. For me, the main benefit of using a
>> scripting language is that it is close to the command-line, which is
>> where Radiance (mostly) lives. If you introduce too much structure,
>> you're getting back to something resembling a C program, and you may
>> as well just write it that way, instead.
>
> There are (at least) two different classes of "scripts" in Radiance.
> Some are indeed little more than a listing of a few commands, and
> in a few cases it looks like they were one-off solutions to a very
> specific problem. Most people will never use those, or they might
> create their own versions. It may or may not be worth to convert
> them, and in some cases the Python version may actually become a
> literal translation without any added structure.

OK, I suppose I would have to see an example of that, preferably something
that wasn't organized around a class. One of the things I have always
disliked about C++ is how you have to dig around in the headers to figure
out what the heck the code is doing. Python at least keeps it together,
but it's still a mess in the sense that the code layout has little to do
with control flow. It's an extra hurdle to understanding I could do
without.

There's still the issue of all the supporting libraries, their many
classes and associated methods.

> The other class are programs like falsecolor or genBSDF, which are
> far beyond that "script" stage. Those are "real" programs in the sense
> that they solve tasks that most people will be confronted with
> regularly. This makes them unlikely to change very significantly over
> time, other than to add features. In those cases, the effort is
> clearly justified to design an object oriented structure and add all
> the bells and whistles most users expect from a complete tool.

Never mind that I just rewrote genBSDF almost from scratch last year when
I introduced rfluxmtx and wrapBSDF with color support, which simplified the
code substantially (and required numerous changes in structure). I was
hoping not to have to do that again, of course....

> You seem to think that object orientation will necessarily make a program
> inflexible. Well, for Java and C++, this is indeed usually the case.
> But it doesn't have to be like that. A well crafted object oriented
> design will make adding features easier, not harder. And Python is one
> of the rare languages, where changing the code is actually fun, and
> not something to be scared of.
>
> This ease of maintenance is also one of the reasons why those things
> should rather *not* be converted to C. There's simply no need to do that,
> as long as we can delegate the number crunching to other tools.

Certain things are definitely easier in a scripting language, or they
wouldn't be useful. Being able to manipulate strings and build command
lines are the most important facilities. Having some ability to do math
and store arrays are also valuable features. Perl and Python are both
superior to the C-shell in that respect, so I agree with you about the
importance of having a decent language for more sophisticated tools.
However, I don't see how Python is less work than Perl given the examples
I've seen. Why not Ruby? Why not any of the other myriad languages out
there? You have your favorite; I have none. I simply went with something
that was familiar and supported, and don't feel like changing canoes
midstream as the expression goes.

>> Perl looks a lot like traditional interpreter shells with the added
>> benefit of more useful built-in commands and expression evaluation.
>> You can open a Perl script and read through it like you're reading a
>> sequence of commands. User-defined functions have a bare-bones call
>> structure and don't have to be defined before they're used, so they
>> don't interrupt the flow as you read through the code.
>
> If you look at Python, you'll find that all that is (or can be) the
> case there as well, just without the uglyness.

As I said, I would have to see a simple example. Your rlux.py ended up
being a bit more complex than its C-shell progenitor... As for ugliness, I
don't really see the differences you do. I have employed languages like
TCL, which I do consider write-only (to use Randoph's term), but Perl is OK
for me.

>> Scripting languages need to be easy to write and easy to read to be
>> useful in my opinion.
>
> But you're still full of praise for Perl...?

I do find Perl easy to read compared to Python, mostly because I don't
have to jump around the class methods or read up on the add-on libraries.
There are plenty of functions in Perl, no doubt about that, but they aren't
such a growing concern.

>> Also, relying heavily on add-on libraries comes at a cost, which is
>> expanded vocabulary one must learn.
>
> Libraries coming included with the language are not "add-on".
> We won't get any bonus points for reinventing the wheel, or for
> dragging stuff around instead of wheeling it.

I'm not saying we need to reinvent the wheel every time, but we could do
without so many wheels. Perhaps it's just a matter of restraint and paring
add-on libraries to a minimum. I don't know.

>> We chain up to 4 commands in genBSDF, which I guess will translate to
>> call_four() in your library?
>
> We're going to have a call_many() then, which will accept and chain an
> arbitrary number of commands. Win_popen() already does that.

OK, I guess that would work.

>>>> We'd still have to switch between data format (-f*)
>>>> command options on the two platforms, or suffer significant
>>>> performance penalties on Unix.
>>> Sorry, not sure what you're talking about there.
>> Well, we may need to devise some tests to be sure this is still a
>> problem, but in the past, Windows would deliver binary files in
>> 128-byte chunks, meaning that the last chunk might have garbage at the
>> end of it that was not actually produced by the program that sent it.
>
> That sounds like a severely broken implementation. I can't possibly
> imagine this still to be the case. If there's a test case, I'll check
> it out.

I don't own a Windows box, so it's difficult for me to produce test
cases. I only hear complaints from people about certain commands not
behaving with binary data on Windows, even when it doesn't go into an
intermediate file. In other words, piping the binary output of one command
into another still screws up. Does Windows create a temporary file when it
does this? Maybe if it's on a FAT filesystem (as Randolph mentioned), this
is the source of the problem. It would be nice to track this down.
Although I don't have a ready solution, it would be good to at least
determine the parameters of the problem. (Radiance's binary files are
immune: octrees, HDR pictures, triangle meshes, even binary matrix data --
it's just the raw IEEE floats & doubles that usually mess up.)

Cheers,
-Greg
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev