From: Roy S. <roy...@ic...> - 2009-12-04 23:48:40
|
I'd like to add a new big feature to GetPot for our use, but it occurred to me that before doing so I should grab the latest from upstream. So I upgraded from GetPot 1.0 to 1.1.18. Then I discovered that our GetPot 1.0 copy had a few extra functions and function overloadings. So I added those. Then I realized that some of these overloadings would be better handled with templates and sstream functionality. So I refactored that. At this point I'm pretty happy with the resulting getpot.h, but because it's got a lot of unexamined changes from upstream and a lot of refactoring and reimplementation from me, I don't want to risk breaking everyone's code just yet. Would people mind testing it out a bit? Just move include/base/getpot-roy.h to include/base/getpot.h and recompile. In theory we should be backwards-compatible, so let me know if anything changes or breaks. --- Roy |
From: Derek G. <fri...@gm...> - 2009-12-05 02:30:00
|
I'll check this on Monday. We've been steadily adding new features to the getpot in libmesh for a while now... And we exercise a TON of getpot... So if it works for me it should be good to go... Derek Sent from my iPhone On Dec 4, 2009, at 4:48 PM, Roy Stogner <roy...@ic...> wrote: > > I'd like to add a new big feature to GetPot for our use, but it > occurred to me that before doing so I should grab the latest from > upstream. So I upgraded from GetPot 1.0 to 1.1.18. Then I discovered > that our GetPot 1.0 copy had a few extra functions and function > overloadings. So I added those. Then I realized that some of these > overloadings would be better handled with templates and sstream > functionality. So I refactored that. > > At this point I'm pretty happy with the resulting getpot.h, but > because it's got a lot of unexamined changes from upstream and a lot > of refactoring and reimplementation from me, I don't want to risk > breaking everyone's code just yet. Would people mind testing it out a > bit? Just move include/base/getpot-roy.h to include/base/getpot.h and > recompile. In theory we should be backwards-compatible, so let me > know if anything changes or breaks. > --- > Roy > > --- > --- > --- > --------------------------------------------------------------------- > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Derek G. <fri...@gm...> - 2009-12-07 17:23:26
|
Ok - we've tried this out. It was missing a piece of functionality... the ability to take "true" or "false" in as a boolean. We added this back in and committed the new getpot-roy.h. We also had to change a few things in our source code... but nothing major. If you're ready to make the switch... do it and send me an email so we can commit our small changes to our source code so our users don't get hosed up. Derek On Fri, Dec 4, 2009 at 7:29 PM, Derek Gaston <fri...@gm...> wrote: > I'll check this on Monday. We've been steadily adding new features to > the getpot in libmesh for a while now... And we exercise a TON of > getpot... So if it works for me it should be good to go... > > Derek > > Sent from my iPhone > > On Dec 4, 2009, at 4:48 PM, Roy Stogner <roy...@ic...> > wrote: > > > > > I'd like to add a new big feature to GetPot for our use, but it > > occurred to me that before doing so I should grab the latest from > > upstream. So I upgraded from GetPot 1.0 to 1.1.18. Then I discovered > > that our GetPot 1.0 copy had a few extra functions and function > > overloadings. So I added those. Then I realized that some of these > > overloadings would be better handled with templates and sstream > > functionality. So I refactored that. > > > > At this point I'm pretty happy with the resulting getpot.h, but > > because it's got a lot of unexamined changes from upstream and a lot > > of refactoring and reimplementation from me, I don't want to risk > > breaking everyone's code just yet. Would people mind testing it out a > > bit? Just move include/base/getpot-roy.h to include/base/getpot.h and > > recompile. In theory we should be backwards-compatible, so let me > > know if anything changes or breaks. > > --- > > Roy > > > > --- > > --- > > --- > > --------------------------------------------------------------------- > > Join us December 9, 2009 for the Red Hat Virtual Experience, > > a free event focused on virtualization and cloud computing. > > Attend in-depth sessions from your desk. Your couch. Anywhere. > > http://p.sf.net/sfu/redhat-sfdev2dev > > _______________________________________________ > > Libmesh-devel mailing list > > Lib...@li... > > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Derek G. <fri...@gm...> - 2009-12-07 17:24:15
|
Alternatively... just let me know when I can switch them... and I will! Thanks! Derek On Mon, Dec 7, 2009 at 10:23 AM, Derek Gaston <fri...@gm...> wrote: > Ok - we've tried this out. It was missing a piece of functionality... the > ability to take "true" or "false" in as a boolean. We added this back in > and committed the new getpot-roy.h. > > We also had to change a few things in our source code... but nothing major. > > If you're ready to make the switch... do it and send me an email so we can > commit our small changes to our source code so our users don't get hosed up. > > Derek > > > On Fri, Dec 4, 2009 at 7:29 PM, Derek Gaston <fri...@gm...> wrote: > >> I'll check this on Monday. We've been steadily adding new features to >> the getpot in libmesh for a while now... And we exercise a TON of >> getpot... So if it works for me it should be good to go... >> >> Derek >> >> Sent from my iPhone >> >> On Dec 4, 2009, at 4:48 PM, Roy Stogner <roy...@ic...> >> wrote: >> >> > >> > I'd like to add a new big feature to GetPot for our use, but it >> > occurred to me that before doing so I should grab the latest from >> > upstream. So I upgraded from GetPot 1.0 to 1.1.18. Then I discovered >> > that our GetPot 1.0 copy had a few extra functions and function >> > overloadings. So I added those. Then I realized that some of these >> > overloadings would be better handled with templates and sstream >> > functionality. So I refactored that. >> > >> > At this point I'm pretty happy with the resulting getpot.h, but >> > because it's got a lot of unexamined changes from upstream and a lot >> > of refactoring and reimplementation from me, I don't want to risk >> > breaking everyone's code just yet. Would people mind testing it out a >> > bit? Just move include/base/getpot-roy.h to include/base/getpot.h and >> > recompile. In theory we should be backwards-compatible, so let me >> > know if anything changes or breaks. >> > --- >> > Roy >> > >> > --- >> > --- >> > --- >> > --------------------------------------------------------------------- >> > Join us December 9, 2009 for the Red Hat Virtual Experience, >> > a free event focused on virtualization and cloud computing. >> > Attend in-depth sessions from your desk. Your couch. Anywhere. >> > http://p.sf.net/sfu/redhat-sfdev2dev >> > _______________________________________________ >> > Libmesh-devel mailing list >> > Lib...@li... >> > https://lists.sourceforge.net/lists/listinfo/libmesh-devel >> > > |
From: Roy S. <roy...@ic...> - 2009-12-07 17:38:20
|
On Mon, 7 Dec 2009, Derek Gaston wrote: > Ok - we've tried this out. It was missing a piece of > functionality... the ability to take "true" or "false" in as a > boolean. We added this back in and committed the new getpot-roy.h. Thanks. Any idea why the bool case wasn't adequately handled by the template? Is it inadvertently upcasting to int or something? I needed the const char* overloading to handle memory management of C strings, but I thought the rest would work with the generic code. > We also had to change a few things in our source code... but nothing > major. I hate to be a pain in the neck, but would you let me know every one of the minor things? Ideally I'd like this new file to be completely backwards compatible both with the libMesh fork of GetPot and with the main GetPot. Everyone who has to change their libMesh code is someone who might be bugging us on the mailing list later, and if there's anything incompatible with GetPot 1.1.18 then it'll be that much harder to talk Frank-Rene Schaefer into merging our changes upstream. Thanks, --- Roy |
From: Derek G. <fri...@gm...> - 2009-12-07 18:01:41
|
On Dec 7, 2009, at 10:38 AM, Roy Stogner wrote: > > On Mon, 7 Dec 2009, Derek Gaston wrote: > >> Ok - we've tried this out. It was missing a piece of >> functionality... the ability to take "true" or "false" in as a >> boolean. We added this back in and committed the new getpot-roy.h. > > Thanks. Any idea why the bool case wasn't adequately handled by the > template? Is it inadvertently upcasting to int or something? I > needed the const char* overloading to handle memory management of C > strings, but I thought the rest would work with the generic code. Well... I actually just changed our small modification to now do a proper template specialization. The issue is that you need a special __convert_to_type for bool so that it looks for "true" or "false". I suspect that the default templated version of __convert_to_type() was failing to convert a std::string with "true" in it to a bool on the line that does "in_string >> retval". In which case the default value gets returned. >> We also had to change a few things in our source code... but nothing >> major. > > I hate to be a pain in the neck, but would you let me know every one > of the minor things? Ideally I'd like this new file to be completely > backwards compatible both with the libMesh fork of GetPot and with the > main GetPot. Everyone who has to change their libMesh code is someone > who might be bugging us on the mailing list later, and if there's > anything incompatible with GetPot 1.1.18 then it'll be that much > harder to talk Frank-Rene Schaefer into merging our changes upstream. parse_input_file() changed to parse_file().... that's it! So, yeah.... that's pretty minor. ;-) Derek |
From: Roy S. <roy...@ic...> - 2009-12-07 18:34:04
|
On Mon, 7 Dec 2009, Derek Gaston wrote: > On Dec 7, 2009, at 10:38 AM, Roy Stogner wrote: > >> >> On Mon, 7 Dec 2009, Derek Gaston wrote: >> >>> Ok - we've tried this out. It was missing a piece of >>> functionality... the ability to take "true" or "false" in as a >>> boolean. We added this back in and committed the new getpot-roy.h. >> >> Thanks. Any idea why the bool case wasn't adequately handled by the >> template? Is it inadvertently upcasting to int or something? I >> needed the const char* overloading to handle memory management of C >> strings, but I thought the rest would work with the generic code. > > Well... I actually just changed our small modification to now do a > proper template specialization. The issue is that you need a > special __convert_to_type for bool so that it looks for "true" or > "false". > > I suspect that the default templated version of __convert_to_type() > was failing to convert a std::string with "true" in it to a bool on > the line that does "in_string >> retval". In which case the default > value gets returned. Ah! Good catch. It looks like you have to pass a boolalpha manipulator to std::istream and descendants before they'll read alphanumeric inputs for booleans. Would you try that (it's my new update) and see if it works? If it doesn't at least pick up "True", "true", "TRUE", and the converse then we'll use a hand-crafted specialization... but although the C++ standard library is pretty anemic, I'd hope it can at least convert strings to bools reliably. > parse_input_file() changed to parse_file().... that's it! > > So, yeah.... that's pretty minor. ;-) Heh, true. But it wasn't an intentional change; I just misread the method name when I was merging some of our forked bits over to the new file! Compatibility with upstream doesn't seem to be an issue here (they only seem to initiate the file parsing in the constructor) so I'll change the name back. --- Roy |
From: Roy S. <roy...@ic...> - 2009-12-07 18:50:59
|
On Mon, 7 Dec 2009, Roy Stogner wrote: > On Mon, 7 Dec 2009, Derek Gaston wrote: > >> I suspect that the default templated version of __convert_to_type() >> was failing to convert a std::string with "true" in it to a bool on >> the line that does "in_string >> retval". In which case the default >> value gets returned. > > Ah! Good catch. It looks like you have to pass a boolalpha > manipulator to std::istream and descendants before they'll read > alphanumeric inputs for booleans. Would you try that (it's my new > update) and see if it works? If it doesn't at least pick up "True", > "true", "TRUE", and the converse then we'll use a hand-crafted > specialization... but although the C++ standard library is pretty > anemic, I'd hope it can at least convert strings to bools reliably. Oh, and this actually brings up another point - using a type T argument is great for inferring return type, and it's great when you actually have a default argument to reduce the size of your config files, but sometimes you want to force a value to be specified in the config, and most of the time you want to scream bloody murder if you see a value that's specified in the config but not parseable. When you want to force a value to be specified, sometimes you can make your "default" into a ludicrously out-of-bounds value and then test to make sure it changed, but obviously that won't work for bools. So we need another form of operator(), which takes an input argument to infer type but which doesn't use it as a default. Maybe add a third argument? inline T operator()(const char* VarName, const T& Default, bool allow_default = true) const; Or maybe that's just overkill, and people should just call assert(have_variable(VarName)) separately, which would work fine as long as we handle unparseable values better. And as for what to do with unparseable values, I'm thinking we just mimic the istream interface? rdstate()/setstate()/clear() in general, and an exception mask in exceptions() (maybe with a #ifdef GETPOT_ENABLE_EXCEPTIONS wrapped around such code for compatibility with aging compilers?) None of this would go in right now; just something to add after I try submitting this upstream. Major feature additions (including the "include other config files" functionality that motivated my messing around with getpot in the first place) can wait until we know whether they're going into getpot 1.3 or just libmesh_forked_getpot 1.1. --- Roy |
From: Derek G. <fri...@gm...> - 2009-12-07 19:40:27
|
On Dec 7, 2009, at 11:50 AM, Roy Stogner wrote: > Oh, and this actually brings up another point - using a type T > argument is great for inferring return type, and it's great when you > actually have a default argument to reduce the size of your config > files, but sometimes you want to force a value to be specified in the > config, and most of the time you want to scream bloody murder if you > see a value that's specified in the config but not parseable. > > When you want to force a value to be specified, sometimes you can make > your "default" into a ludicrously out-of-bounds value and then test to > make sure it changed, but obviously that won't work for bools. So we > need another form of operator(), which takes an input argument to > infer type but which doesn't use it as a default. Maybe add a third > argument? > > inline T operator()(const char* VarName, const T& Default, bool allow_default = true) const; > > Or maybe that's just overkill, and people should just call > assert(have_variable(VarName)) separately, which would work fine as > long as we handle unparseable values better. We struggle with this right now... we usually go the route of setting something out of bounds... I suppose that have_variable() might be a better idea... > None of this would go in right now; just something to add after I try > submitting this upstream. Major feature additions (including the > "include other config files" functionality that motivated my messing > around with getpot in the first place) can wait until we know whether > they're going into getpot 1.3 or just libmesh_forked_getpot 1.1. Can you include other config files now?!?! That's something my users actually want right now... Derek |
From: Roy S. <roy...@ic...> - 2009-12-07 20:12:09
|
On Mon, 7 Dec 2009, Derek Gaston wrote: > On Dec 7, 2009, at 11:50 AM, Roy Stogner wrote: > >> None of this would go in right now; just something to add after I try >> submitting this upstream. Major feature additions (including the >> "include other config files" functionality that motivated my messing >> around with getpot in the first place) can wait until we know whether >> they're going into getpot 1.3 or just libmesh_forked_getpot 1.1. > > Can you include other config files now?!?! That's something my users actually want right now... No, not yet - I figured before I made such a big change I should get us up to date with the latest GetPot, which is turning out to be a little more involved than initially anticipated. In particular, when I was hunting down Frank Schaefer's email address I noticed that he'd changed the licensing on us: his LGPL now "is only valid in case that it is not used for the production or development of applications dedicated to military industry". Now, I'm pretty sure NASA's not going to turn FIN-S into the next reentry warhead simulator, and I don't *think* INL is using nuclear reactors research as a cover for designing the next superweapon, but regardless we're not going to put anything critical into libMesh that violates the Open Source Definition. So unless he agrees to go back to the pure LGPL the idea of "submitting upstream" becomes moot - we'll have to fork version 1.1, that being the latest I can find without the "unofficial peace version" of the license. --- Roy |
From: Derek G. <fri...@gm...> - 2009-12-07 20:25:05
|
I've always noticed that clause on his website... never new it was actually in the source! That is just a weird clause in general... and certainly libMesh has no business having a clause like that in it. It's really only going to end up being bad for him.' BTW: The boolalpha thing doesn't really work out. It's not case insensitive for one thing... Derek On Dec 7, 2009, at 1:11 PM, Roy Stogner wrote: > > > On Mon, 7 Dec 2009, Derek Gaston wrote: > >> On Dec 7, 2009, at 11:50 AM, Roy Stogner wrote: >> >>> None of this would go in right now; just something to add after I try >>> submitting this upstream. Major feature additions (including the >>> "include other config files" functionality that motivated my messing >>> around with getpot in the first place) can wait until we know whether >>> they're going into getpot 1.3 or just libmesh_forked_getpot 1.1. >> >> Can you include other config files now?!?! That's something my users actually want right now... > > No, not yet - I figured before I made such a big change I should get > us up to date with the latest GetPot, which is turning out to be a > little more involved than initially anticipated. > > In particular, when I was hunting down Frank Schaefer's email address > I noticed that he'd changed the licensing on us: his LGPL now "is > only valid in case that it is not used for the production or > development of applications dedicated to military industry". Now, I'm > pretty sure NASA's not going to turn FIN-S into the next reentry > warhead simulator, and I don't *think* INL is using nuclear reactors > research as a cover for designing the next superweapon, but regardless > we're not going to put anything critical into libMesh that violates > the Open Source Definition. So unless he agrees to go back to the > pure LGPL the idea of "submitting upstream" becomes moot - we'll have > to fork version 1.1, that being the latest I can find without the > "unofficial peace version" of the license. > --- > Roy |
From: Roy S. <roy...@ic...> - 2009-12-07 20:34:46
|
On Mon, 7 Dec 2009, Derek Gaston wrote: > BTW: The boolalpha thing doesn't really work out. It's not case > insensitive for one thing... Bah, I was afraid of that. Don't worry, I'm sure C++ will handle True and False in C++1x, or maybe C++2x at most. Right after they figure out that it might be a good idea to allow std::ifstream to be constructed with a std::string filenames and not just const char* filenames. I should have known better than to trust the C++ standard library if it doesn't even trust itself yet. ;-) Would you reenable the bool specialization, maybe add a comment explaining the operator>>(bool) failings? Thanks, --- Roy |
From: Roy S. <roy...@ic...> - 2009-12-08 23:02:27
|
On Mon, 7 Dec 2009, Derek Gaston wrote: > BTW: The boolalpha thing doesn't really work out. It's not case > insensitive for one thing... I've reverted it, and reverted the whole file to branch off of the 1.1 version that was still under pure LGPL. Works for me, but would you mind testing yet-another-revision before we replace the current getpot.h? Thanks, --- Roy |
From: Derek G. <fri...@gm...> - 2009-12-08 23:03:41
|
Is the one you want tested now in getpot-roy.h? Derek On Dec 8, 2009, at 4:02 PM, Roy Stogner wrote: > > On Mon, 7 Dec 2009, Derek Gaston wrote: > >> BTW: The boolalpha thing doesn't really work out. It's not case >> insensitive for one thing... > > I've reverted it, and reverted the whole file to branch off of the 1.1 > version that was still under pure LGPL. Works for me, but would you > mind testing yet-another-revision before we replace the current > getpot.h? > > Thanks, > --- > Roy |
From: Roy S. <roy...@ic...> - 2009-12-08 23:19:07
|
Yes, thanks. On Tue, 8 Dec 2009, Derek Gaston wrote: > Is the one you want tested now in getpot-roy.h? > > Derek > > On Dec 8, 2009, at 4:02 PM, Roy Stogner wrote: > >> >> On Mon, 7 Dec 2009, Derek Gaston wrote: >> >>> BTW: The boolalpha thing doesn't really work out. It's not case >>> insensitive for one thing... >> >> I've reverted it, and reverted the whole file to branch off of the 1.1 >> version that was still under pure LGPL. Works for me, but would you >> mind testing yet-another-revision before we replace the current >> getpot.h? >> >> Thanks, >> --- >> Roy > > |
From: Roy S. <roy...@ic...> - 2009-12-15 19:09:36
|
Did you have time to test the current version yet? I'm looking over it now, and it looks like it should be really easy to add the include files functionality. Here's my thoughts for the extended API: If text in brackets has whitespace in it, it is interpreted as a directive rather than as a section name. I.e. [include.chemistry.in] is a section name, whereas [include chemistry.in] is an include directive that reads the contents of the chemistry.in file (and of any files that chemistry.in includes, depth first). On the other hand, it would be just as easy to eschew writing Yet Another Meta-Language, and instead just run all input files through a cpp pipe before parsing the result. Preferences, anyone? --- Roy On Tue, 8 Dec 2009, Roy Stogner wrote: > Yes, thanks. > > On Tue, 8 Dec 2009, Derek Gaston wrote: > >> Is the one you want tested now in getpot-roy.h? >> >> Derek >> >> On Dec 8, 2009, at 4:02 PM, Roy Stogner wrote: >> >>> >>> On Mon, 7 Dec 2009, Derek Gaston wrote: >>> >>>> BTW: The boolalpha thing doesn't really work out. It's not case >>>> insensitive for one thing... >>> >>> I've reverted it, and reverted the whole file to branch off of the 1.1 >>> version that was still under pure LGPL. Works for me, but would you >>> mind testing yet-another-revision before we replace the current >>> getpot.h? >>> >>> Thanks, >>> --- >>> Roy >> >> > |
From: Derek G. <fri...@gm...> - 2009-12-16 16:31:35
|
On Dec 15, 2009, at 12:09 PM, Roy Stogner wrote: > Did you have time to test the current version yet? Your new getpot works fine with our test suite... feel free to replace the old one. Derek |
From: Derek G. <fri...@gm...> - 2009-12-17 16:04:50
|
Roy... do you want to move that new getpot over now? Or can I do it in a checkin I'm readying now? It would be nice to do it this morning since the other small changes I'm checking in are going to force my users to update libmesh anyway... Let me know, Derek |
From: Roy S. <roy...@ic...> - 2009-12-17 16:07:10
|
On Thu, 17 Dec 2009, Derek Gaston wrote: > Roy... do you want to move that new getpot over now? Just did it 5 seconds before I got this email. :-D Sorry, I meant to do it last night, but I had to leave before my last set of tests finished. --- Roy |
From: Derek G. <fri...@gm...> - 2009-12-17 16:31:18
|
On Dec 17, 2009, at 9:06 AM, Roy Stogner wrote: > Just did it 5 seconds before I got this email. :-D > > Sorry, I meant to do it last night, but I had to leave before my last > set of tests finished. No problem! Thanks! Derek |
From: Roy S. <roy...@ic...> - 2009-12-07 23:46:27
|
On Mon, 7 Dec 2009, Roy Stogner wrote: > So unless he agrees to go back to the pure LGPL the idea of > "submitting upstream" becomes moot - we'll have to fork version 1.1, > that being the latest I can find without the "unofficial peace > version" of the license. Just heard back from Frank Schäfer - he needs time both to decide on the licensing and to incorporate some other contributions he's received, so I'm going to back us off to a 1.1-based fork for now. --- Roy |
From: Derek G. <fri...@gm...> - 2009-12-15 19:18:46
|
On Dec 15, 2009, at 12:09 PM, Roy Stogner wrote: > Did you have time to test the current version yet? I have not. Thanks for reminding me. > I'm looking over it now, and it looks like it should be really easy to > add the include files functionality. > > Here's my thoughts for the extended API: > > If text in brackets has whitespace in it, it is interpreted as a > directive rather than as a section name. I.e. > [include.chemistry.in] is a section name, whereas > [include chemistry.in] is an include directive that reads the contents > of the chemistry.in file (and of any files that chemistry.in includes, > depth first). That's a little twiddly for me. What about using some other type of brackets? Like <> so it would be: <chemistry.in> > On the other hand, it would be just as easy to eschew writing Yet > Another Meta-Language, and instead just run all input files through a > cpp pipe before parsing the result. We already do something like this... we just open multiple getpot objects to multiple input files and parse each one. It works _ok_ but there is some crappy code in there.... Derek |
From: Roy S. <roy...@ic...> - 2009-12-15 19:58:34
|
On Tue, 15 Dec 2009, Derek Gaston wrote: > On Dec 15, 2009, at 12:09 PM, Roy Stogner wrote: > >> If text in brackets has whitespace in it, it is interpreted as a >> directive rather than as a section name. I.e. >> [include.chemistry.in] is a section name, whereas >> [include chemistry.in] is an include directive that reads the contents >> of the chemistry.in file (and of any files that chemistry.in includes, >> depth first). > > That's a little twiddly for me. What about using some other type of brackets? Like <> so it would be: > > <chemistry.in> Parsing could be uglier. GetPot already uses "{}" for variable substitution and "Dollar Bracket Expressions", and their DBE operators include "<->", "<", "<=", ">", and ">=". >> On the other hand, it would be just as easy to eschew writing Yet >> Another Meta-Language, and instead just run all input files through a >> cpp pipe before parsing the result. > > We already do something like this... we just open multiple getpot > objects to multiple input files and parse each one. It works _ok_ > but there is some crappy code in there.... More importantly, the code has to be in user apps, it has to be repeated for each new app, and you've either got to implement your own "search-for-include-directives" code or you've got to hard-code the list of multiple input files. It'd be better in the library. We just need to figure out an API that works for everybody, is easy to add, and doesn't include too many nasty side effects. That's what I like about the first version: effectively no nasty side effects, since tokens like "[two words]" are pretty much bugs in a current version getpot input file. Using cpp would be much nicer than gradually reimplementing cpp poorly, but it would need to be a non-default option since it would barf at input files which use '#' as a comment character. What if we make directives into additional DBE operators? i.e. ${include chemistry.in} --- Roy |
From: Derek G. <fri...@gm...> - 2009-12-15 20:01:41
|
On Dec 15, 2009, at 12:58 PM, Roy Stogner wrote: > What if we make directives into additional DBE operators? > i.e. ${include chemistry.in} That sounds good to me. Derek |
From: Roy S. <roy...@ic...> - 2009-12-15 20:21:51
|
On Tue, 15 Dec 2009, Derek Gaston wrote: > On Dec 15, 2009, at 12:58 PM, Roy Stogner wrote: > >> What if we make directives into additional DBE operators? >> i.e. ${include chemistry.in} > > That sounds good to me. It'll be an additional hassle on our side: we currently use the Dakota preprocessor, which parses DBEs itself and so doesn't pass them through to getpot. But that's something we can work around; this sounds like the most consistent way to extend the GetPot API. --- Roy |