Am 2016-03-22 01:34, schrieb Gregory J. Ward:
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
From: Georg Mischler <schor...@schorsch.com>
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! :P
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 <schor...@schorsch.com>
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 <schor...@schorsch.com>
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 <schor...@schorsch.com>
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
Radiance-dev@radiance-online.org
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
Radiance-dev@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-dev
_______________________________________________
Radiance-dev mailing list
Radiance-dev@radiance-online.org
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
Radiance-dev@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-dev
