Sounds pretty good, and we don't even have to run the server. :-) 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 >
_______________________________________________ Radiance-dev mailing list [email protected] http://www.radiance-online.org/mailman/listinfo/radiance-dev
