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" <schor...@schorsch.com> 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 >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
