From: Karol L. <kar...@kn...> - 2007-01-29 23:47:09
|
It occurred to me that it might be beneficial to have two functions in the LogFile class that should be called before and after logfiles of any type are parsed. For instance, when working the GAMESS parser, I saw there was no final progress update and conversion of attributes to arrays. With these functions, that won't happen for any new parsers, changes can be made for all of them in one place, and the code will be clearer. Basically, everything in the parse() function of a parser before the "for line in inputfile" loop would go i nthe first function, and everything after in the second. As far as I can tell, there are no differences here between parsers, so is there a reason not to do this? To do this, however, inputfile, nstep, and oldstep (maybe something else, also?) need to be parser attributes. If this seems like a good idea, I'd be happy to do the necessary changes in a few days. Karol -- written by Karol Langner Tue Jan 30 00:26:31 CET 2007 |
From: Noel O'B. <bao...@gm...> - 2007-01-30 08:04:54
|
Some thoughts: The final conversion of attributes to arrays may be different in each case, and so cannot be shared across parsers. Any additional shared code, e.g. final progress update, should be called from the end of the .parse(), rather than having the user call it. On 29/01/07, Karol Langner <kar...@kn...> wrote: > It occurred to me that it might be beneficial to have two functions in the > LogFile class that should be called before and after logfiles of any type are > parsed. For instance, when working the GAMESS parser, I saw there was no > final progress update and conversion of attributes to arrays. With these > functions, that won't happen for any new parsers, changes can be made for all > of them in one place, and the code will be clearer. > > Basically, everything in the parse() function of a parser before the "for line > in inputfile" loop would go i nthe first function, and everything after in > the second. As far as I can tell, there are no differences here between > parsers, so is there a reason not to do this? > > To do this, however, inputfile, nstep, and oldstep (maybe something else, > also?) need to be parser attributes. > > If this seems like a good idea, I'd be happy to do the necessary changes in a > few days. > > Karol > > -- > written by Karol Langner > Tue Jan 30 00:26:31 CET 2007 > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
From: Karol L. <kar...@kn...> - 2007-01-30 08:50:35
|
On Tuesday 30 of January 2007 09:04, Noel O'Boyle wrote: > Some thoughts: The final conversion of attributes to arrays may be > different in each case, and so cannot be shared across parsers. Any > additional shared code, e.g. final progress update, should be called > from the end of the .parse(), rather than having the user call it. Can you give an example of when the conversion of attributes to arrays would be different between two parsers? I thought the idea was for attributes to be the same for all parsers. As to calling the function(s) I'm proposing, I wasn't thinking exactly what you said - calling them from the beginning/end of .parse(). The user sees no changes here. I have however, a different idea. What if .parse() were defined for the generic class LogFile, and it did all the "generic" things, and also called self.extract(), which would contain the "for line in self.inputfile" loop that is specific to each parser (effectively replacing the current.parse()). This way, we would have only one function more and all the benifits, and again no change for the user. Karol Karol -- written by Karol Langner Tue Jan 30 09:43:45 CET 2007 |
From: Noel O'B. <bao...@gm...> - 2007-01-30 09:31:27
|
On 30/01/07, Karol Langner <kar...@kn...> wrote: > On Tuesday 30 of January 2007 09:04, Noel O'Boyle wrote: > > Some thoughts: The final conversion of attributes to arrays may be > > different in each case, and so cannot be shared across parsers. Any > > additional shared code, e.g. final progress update, should be called > > from the end of the .parse(), rather than having the user call it. > > Can you give an example of when the conversion of attributes to arrays would > be different between two parsers? I thought the idea was for attributes to be > the same for all parsers. The net effect is the same, but in some cases the attribute is created as an array in the main loop, in others it is built up incremently as a list of lists, and then converted afterwards, outside the loop. Also found outside the loop are instances where if a particular attribute has not been set, it is set to a default value. But after thinking a bit, I guess you're right, the conversion code at least can be moved into a common function. If moenergies is already an array, and you try to convert it, it doesn't cause any harm. > As to calling the function(s) I'm proposing, I wasn't thinking exactly what > you said - calling them from the beginning/end of .parse(). The user sees no > changes here. > > I have however, a different idea. What if .parse() were defined for the > generic class LogFile, and it did all the "generic" things, and also called > self.extract(), which would contain the "for line in self.inputfile" loop > that is specific to each parser (effectively replacing the current.parse()). > This way, we would have only one function more and all the benifits, and > again no change for the user. Indeed, I prefer this too. Noel |
From: Adam T. <a-t...@st...> - 2007-01-30 16:39:56
|
>> I have however, a different idea. What if .parse() were defined >> for the >> generic class LogFile, and it did all the "generic" things, and >> also called >> self.extract(), which would contain the "for line in >> self.inputfile" loop >> that is specific to each parser (effectively replacing the >> current.parse()). >> This way, we would have only one function more and all the >> benifits, and >> again no change for the user. > > Indeed, I prefer this too. I agree that this is a good idea. I also think ccopen and others should check to see if the logfile exists, and if not, print an error/ warning about it. Adam |
From: Karol L. <kar...@kn...> - 2007-01-30 23:44:39
|
On Tuesday 30 of January 2007 17:39, Adam Tenderholt wrote: > >> I have however, a different idea. What if .parse() were defined > >> for the > >> generic class LogFile, and it did all the "generic" things, and > >> also called > >> self.extract(), which would contain the "for line in > >> self.inputfile" loop > >> that is specific to each parser (effectively replacing the > >> current.parse()). > >> This way, we would have only one function more and all the > >> benifits, and > >> again no change for the user. > > > > Indeed, I prefer this too. > > I agree that this is a good idea. I also think ccopen and others > should check to see if the logfile exists, and if not, print an error/ > warning about it. > > Adam Well, to start this I added a parse() method to the LogFile class and renamed parse() to extract() in the parsers. Take a look if the general idea is suitable. If so, we can start moving things to the generic method. I checked all the tests and regression tests - nothing broken. Karol -- written by Karol Langner Wed Jan 31 00:38:48 CET 2007 |
From: Karol L. <kar...@kn...> - 2007-02-01 13:38:27
|
On Tuesday 30 of January 2007 17:39, you wrote: > I also think ccopen and others > should check to see if the logfile exists, and if not, print an error/ > warning about it. I added and IOError exception to the call to openlogfile() in ccopen, which returns None. Karol -- written by Karol Langner Thu Feb 1 14:35:35 CET 2007 |