[Radiance-general] Re: Python Radiance Package

Sounds pretty good, and we don't even have to run the server. :slight_smile:

Sign me up. I don't know how much I'll be contributing--I've got, as my
managers and colleagues remind me, plenty of other work--but I want to at
least have the opportunity.

···

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs

On Mon, Nov 8, 2010 at 9:13 PM, David Smith <[email protected]> wrote:

Wow, thanks to all who replied. I'll try to address some of the raised
eyebrows now, and answer the more technical ones later.

My goal was an easier way to do some analysis that would require more
than simple shell scripts. Or rather, a way to do some things that
would probably be easier in a higher level language. I just so happen
to do a lot in Python, and I think it's a relatively simple language
to pick up, and its syntax looks like pseudocode.

Some more complicated scripts can get hard to follow with lots of
system calls, stringing together variables, or keeping track of and
deleting temporary files. I think that a Python package could be more
user friendly by making a simple interface and taking care of that
sort of thing automatically and invisibly. Also it could take
advantage of some of the more interesting Python capabilities such as
using distributed tasks (multiprocessor/multi-machine), pre-written
data processing libraries, image libraries, etc.

Since, as has been pointed out, the same code can run essentially
unmodified on any modern system that can run Radiance, there is the
possibility that this can create an easy way to exchange ideas and
create novel approaches to analysis. The architecture scripting
community is surprisingly active.

However, all I really wanted to do initially was provide a simple
interface back to Radiance, then step back and maintain/optimize it. I
hadn't given much technical thought other than it ought to at least
start out as a wrapper program. Because of the modularity of it all,
that could be changed later. I wasn't really aiming to replace things
like the csh scripts, although this would make it easy for someone to
do so if they wanted. I wanted for it to be as transparent as possible
through to Radiance proper.

Finally, I really appreciate the volunteers. I'm not a programming
novice, but I'm certainly not a guru either. Collaboration is much
appreciated.

I've registered a Google code page (for now, Mercurial, because I've
never used it and want to learn it - I hear it's like subversion with
the benefits of git) at http://code.google.com/p/python-radiance . I
think that the conversation should be continued in the
code-development thread, where it will likely get more technical.

--Dave

On Mon, Nov 8, 2010 at 1:33 PM, Randolph M. Fritz <[email protected]> wrote:

If people are interested, the Labs is offering subversion server space on
one of our servers. When we get the website update project a bit further
along, we'll be able to give the project a page, too.

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs

On 2010-11-08 08:58:45 -0800, Thomas Bleicher said:

On Mon, Nov 8, 2010 at 11:36 AM, Greg Ward <[email protected]> >>> wrote:

Well, it sounds like there is significant groundswell around this idea.
I suggest that interested parties/developers organize a host site for
this effort and someone (Dave?) take charge of the project.

Google code projects are easy to set up and almost everyone
in this thread already has a gmail account. It may be more difficult
to find a source control system that everybody agrees on ...

Ongoing maintenance is something to think about as well,

as new Radiance releases will likely continue to have some
minor changes and some major additions.

Since everybody is happy with a simple 'subprocess' wrapper
around the Radiance binaries there shouldn't be much ongoing
maintenance. Python 2 vs 3 is more likely to cause additional
work than the Radiance interface.

However, I can see that an additional advantage of this project
could be that the remaining CSH scripts (and possibly Perl scripts)
in the main Radiance distribution get finally pythonized. In that
case should the new scripts be kept separately or should they
find their way back into the distribution?

Thomas

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs

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

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

I could drop some debian packaging into th erepository as soon as there is
something worth to be packaged. Just ping me.

Bernd

···

On 11/09/2010 06:13 AM, David Smith wrote:

Finally, I really appreciate the volunteers. I'm not a programming
novice, but I'm certainly not a guru either. Collaboration is much
appreciated.

I've registered a Google code page (for now, Mercurial, because I've
never used it and want to learn it - I hear it's like subversion with
the benefits of git) at http://code.google.com/p/python-radiance . I
think that the conversation should be continued in the
code-development thread, where it will likely get more technical.

--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F