From: Arlindo da S. <da...@al...> - 2008-01-28 14:05:36
|
All, First of all, congratulations to Jennifer and Brian on the milestone! I am very much looking forward to making v2 the focus for the opengrads activities. I was able to download Jennifer's sources last night and relatively easily build it with the new supplibs. For convenience I built --without-hdf as I wanted to see v2 in action rather than tinker with baselibs. Was able to start it from the command classic line as well as through the pygrads interpreter. (PyGrADS has limit functionality as I need the IPC extension to exchange variables with python, something *not* used in pytests.) Yes, the "-u" switch works out of the box. This means that the pytests should work pretty much out of the box except for small adjustments for new executable names, etc. However, I had to go to bed before I could play it. My approach was as follows. The autoconf scripts in the v1.9 code base appear in better shape than in v2.0.a1 (they are supplibs v2 ready, include Pat's dynamic supplibs, and have other cleanup and more robust discovery macros). Therefore, I started with our configure.ac and Makefile.am, replaced all the files in src/, doc/, lib/ and etc/ with the v2.0.a1versions. Then I merged the src/Makefile.am with the what we had from v1.9 and voila it built grads and gradsdap. I still need to do a bit clean as I cut a couple of corners to get it done quickly. But the message is: we should be able to v2.0.a1 building with the supplibs, Pat's dyn supplibs feature, and pytests in a relatively short amount of time. This will allow builds on all the platforms supported by the new supplibs, including windows. Here is my proposed roadmap: 1. Place all current opengrads development under a GRADS1_DEV_BRANCH 2. Import GrADS v2.0.a1 into our CVS repo, in the usual COLA vendor branch, release tag v2_0_a1 3. Patch the hdf4 in the current supplibs (I expect this to be a single line change in the GNUmakefile) and rebuild them. Since I still have my sandboxes around I may only have to rebuild hdf4 and re-tar. 4. Clean up what I did last night, making sure I have a full build --with-hdf, and make sure "make check" and the pytests work. I'll need to iterate with Pat to make sure the dynamic supplibs also work. I'll then check this into the trunk, merging it with the COLA vendor branch. From that point on, checking out module "Grads" will produce the v2 codebase. At this point we can submit it to COLA as a patch or simply give them a tag as Jennifer has repository privileges. If COLA is interested, I can help out with builds at the platforms we have supplibs for; hoop is also setup to build on solaris. My next priority would be to add the hooks for dynamically linked extensions as this is the bread-and-butter of opengrads. Brian/Jennifer: I could have a first crack at adding the dynamic UDFs/UDFs hooks, and go over with you in a face-to-face meeting at COLA. Or else, I can be available for questions if you would prefer to have a first crack yourselves. Let me know. Porting the current extensions to v2 deserves its own roadmap. Let's postpone this discussion. As always, any comments on this proposal is greatly appreciated. Cheers, Arlindo -- Arlindo da Silva da...@al... |
From: Brian D. <do...@co...> - 2008-01-30 00:16:18
|
Arlindo, we will be working on drafting an interface specification. The idea is that if the specification is followed, the UDF developer can have confidence his/her code will work with future COLA GrADS releases. We'll ask for comments once we have something... Brian On Jan 28, 2008, at 9:05 AM, Arlindo da Silva wrote: > > Brian/Jennifer: I could have a first crack at adding the dynamic > UDFs/UDFs hooks, and go over with you in a face-to-face meeting at > COLA. Or else, I can be available for questions if you would prefer > to have a first crack yourselves. Let me know. > |
From: Arlindo da S. <da...@al...> - 2008-01-30 00:55:36
|
On Jan 29, 2008 4:54 PM, Brian Doty <do...@co...> wrote: > Arlindo, we will be working on drafting an interface specification. > The idea is that if the specification is followed, the UDF developer > can have confidence his/her code will work with future COLA GrADS > releases. We'll ask for comments once we have something... Brian > I look forward to it. One way we have done this in the ESMF is to have the earlier discussion around "use case scenarios" rather than a detailed API spec. Kind like test-driven design: write the examples first, then formalize the API and eventually code. Another suggestion I'd have is to think about UDFs and UDCs (user defined commands) from the get go. These 2 go very well together as the UDCs can be used to configure the UDFs, therefore keeping the argument list manageable for complex UDFs. And in some cases all you need is an UDC, not an UDF. Let me know of I can be of any help. Arlindo -- Arlindo da Silva da...@al... |