Menu
▾
▴
babeldoc-devel
|
From: David G. <dg...@co...> - 2003-08-06 00:35:27
|
It's normal for a program that prints a help screen to end so that it can be re-run with options. The process tool, for example, does this, but the scanner tool will print the help options and then continue to execute. Is this the intended functionality? If not, I'd be happy to change it, because it's driving me slightly batty... :-) David -- David Glick Transmit Consulting, Inc 619-475-4052 dg...@tr... |
|
From: Bruce M. <br...@mc...> - 2003-08-06 00:39:44
|
Do it. On Tuesday 05 August 2003 08:46 pm, David Glick wrote: > It's normal for a program that prints a help screen to end so that it can > be re-run with options. The process tool, for example, does this, but the > scanner tool will print the help options and then continue to execute. Is > this the intended functionality? If not, I'd be happy to change it, > because it's driving me slightly batty... :-) > > > David |
|
From: Dejan K. <dej...@nb...> - 2003-08-06 08:12:43
|
Probably my mistake ;) Since scanner tool has been completly rewritten there are probably more things like this one... I guess it will be OK in 1.2 version! Dejan ----- Original Message ----- From: "David Glick" <dg...@co...> To: <bab...@li...> Sent: Wednesday, August 06, 2003 2:46 AM Subject: [Babeldoc-devel] Scanner tool and '-h' option? > It's normal for a program that prints a help screen to end so that it can be > re-run with options. The process tool, for example, does this, but the > scanner tool will print the help options and then continue to execute. Is > this the intended functionality? If not, I'd be happy to change it, because > it's driving me slightly batty... :-) > > > David > > -- > David Glick > Transmit Consulting, Inc > 619-475-4052 > dg...@tr... > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel |
|
From: Dejan K. <dej...@nb...> - 2003-08-06 09:29:25
|
After looking at code you have commited I doubt if this is really good solution... Since h option belongs to parrent class, BabeldocCommand, I guess that class is right place for handling this situation, otherwise, all other commands might need dealing with it. So, what do you think about having System.exit call inside printUsage method? Also, some refactoring is probably needed inside BabeldocCommand class. There are few things that I don't like right now: 1. This should be abstract class, right? Making BabeldocCommand instance does not make a sence. 2. We should not expect that subclasses will call super implementation when overide some method. For example in current implementation, subclass should call super.execute() when overriding execute() method. Better solution would be "Don't call me - I'll call you!" (Hollywood) principle. That is, BabeldocCommand should have one method, for example executeBabeldocCommand() that should call abstract execute() method. That way, subclass will be forced to implement execute(), and it should not worry about super implementation if it does not need to change default behaviour. 3. We should make all methods that subclasses need to implement abstract. That way we can make sure that it will be implemented. What do you think about this? I think it is quite easy to change this, but since many classes extend this class we need to agree with it! Dejan ----- Original Message ----- From: "David Glick" <dg...@co...> To: <bab...@li...> Sent: Wednesday, August 06, 2003 2:46 AM Subject: [Babeldoc-devel] Scanner tool and '-h' option? > It's normal for a program that prints a help screen to end so that it can be > re-run with options. The process tool, for example, does this, but the > scanner tool will print the help options and then continue to execute. Is > this the intended functionality? If not, I'd be happy to change it, because > it's driving me slightly batty... :-) > > > David > > -- > David Glick > Transmit Consulting, Inc > 619-475-4052 > dg...@tr... > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel |
|
From: David G. <dg...@co...> - 2003-08-06 12:20:11
|
Hi Dejan, My opinion is to avoid multiple exit points in programs where possible, even though this is a trivial case and probably won't make much of an impact. As an alternative, what about throwing an ApplicationExit() exception that can be caught by BabeldocCommand to exit? If you think this is overly complicated, then I'm fine with System.exit() in printUsage(). I also agree that the current classes that extend BabeldocCommand should be refactored; I've discovered at least one side effect that is causing problems in Scanner, and will probably lead to further problems elsewhere in the future. Responding to your questions with questions of my own: 1. I'm not yet very familiar with the structure of the program, but if BabeldocCommand is made abstract, what happens when the user types "babeldoc -h" ? In this instance (heh, heh), will a BabeldocCommand class be instantiated? 2. I agree with this point. It seems that the purpose of the current implementation is to perform some common pre-processing for all the tools, and I think that it would be relatively easy to restructure things so that the 'Hollywood Principle" applies (this principle, as detailed by the great and wise Dejan Krsmanovic in his excellent programming book "How Your Lousy Programming Is Helping Me Retire to a Life of Sin and Decadence", describes some of the fundamental reasons that he's rich and we're not). 3. I think this is generally good programming practice, and makes it much easier for those trying to understand the implementation of the system (i.e. me). David On Wednesday 06 August 2003 2:27 am, Dejan Krsmanovic wrote: > After looking at code you have commited I doubt if this is really good > solution... Since h option belongs to parrent class, BabeldocCommand, I > guess that class is right place for handling this situation, otherwise, all > other commands might need dealing with it. So, what do you think about > having System.exit call inside printUsage method? > > Also, some refactoring is probably needed inside BabeldocCommand class. > There are few things that I don't like right now: > 1. This should be abstract class, right? Making BabeldocCommand instance > does not make a sence. > 2. We should not expect that subclasses will call super implementation when > overide some method. For example in current implementation, subclass should > call super.execute() when overriding execute() method. Better solution > would be "Don't call me - I'll call you!" (Hollywood) principle. That is, > BabeldocCommand should have one method, for example > executeBabeldocCommand() that should call abstract execute() method. That > way, subclass will be forced to implement execute(), and it should not > worry about super implementation if it does not need to change default > behaviour. > 3. We should make all methods that subclasses need to implement abstract. > That way we can make sure that it will be implemented. > > What do you think about this? I think it is quite easy to change this, but > since many classes extend this class we need to agree with it! > > Dejan > > > ----- Original Message ----- > From: "David Glick" <dg...@co...> > To: <bab...@li...> > Sent: Wednesday, August 06, 2003 2:46 AM > Subject: [Babeldoc-devel] Scanner tool and '-h' option? > > > It's normal for a program that prints a help screen to end so that it can > > be > > > re-run with options. The process tool, for example, does this, but the > > scanner tool will print the help options and then continue to execute. > > Is this the intended functionality? If not, I'd be happy to change it, > > because > > > it's driving me slightly batty... :-) > > > > > > David > > > > -- > > David Glick > > Transmit Consulting, Inc > > 619-475-4052 > > dg...@tr... > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are available now. > > Download today and enter to win an XBOX or Visual Studio .NET. > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > > _______________________________________________ > > Babeldoc-devel mailing list > > Bab...@li... > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel -- David Glick Transmit Consulting, Inc 619-475-4052 dg...@tr... |
|
From: Dejan K. <dej...@nb...> - 2003-08-06 12:39:36
|
Hi David! > Hi Dejan, > > My opinion is to avoid multiple exit points in programs where possible, even > though this is a trivial case and probably won't make much of an impact. As > an alternative, what about throwing an ApplicationExit() exception that can > be caught by BabeldocCommand to exit? If you think this is overly > complicated, then I'm fine with System.exit() in printUsage(). I would not use exceptions in this case. In fact I think if we apply idea that I suggested (abstract method and Holywood principle) there will be no need for mutiple exit points, too. > I also agree that the current classes that extend BabeldocCommand should be > refactored; I've discovered at least one side effect that is causing problems > in Scanner, and will probably lead to further problems elsewhere in the > future. > > Responding to your questions with questions of my own: > > 1. I'm not yet very familiar with the structure of the program, but if > BabeldocCommand is made abstract, what happens when the user types "babeldoc > -h" ? In this instance (heh, heh), will a BabeldocCommand class be > instantiated? Hmm. Try it ;) Anyway enrty point in program is com.babeldoc.core.Main class and it will make instance based on provided argument and appropriate class. Mapping between program argument and command classes can be found in service/query.properties file. So, BabeldocCommand cannot be instantiated since it does not exist in this mapping! > 2. I agree with this point. It seems that the purpose of the current > implementation is to perform some common pre-processing for all the tools, > and I think that it would be relatively easy to restructure things so that > the 'Hollywood Principle" applies (this principle, as detailed by the great > and wise Dejan Krsmanovic in his excellent programming book "How Your Lousy > Programming Is Helping Me Retire to a Life of Sin and Decadence", describes > some of the fundamental reasons that he's rich and we're not). Can you send me pdf version of that book, please! ;) Dejan > > 3. I think this is generally good programming practice, and makes it much > easier for those trying to understand the implementation of the system (i.e. > me). > > > David > > > On Wednesday 06 August 2003 2:27 am, Dejan Krsmanovic wrote: > > After looking at code you have commited I doubt if this is really good > > solution... Since h option belongs to parrent class, BabeldocCommand, I > > guess that class is right place for handling this situation, otherwise, all > > other commands might need dealing with it. So, what do you think about > > having System.exit call inside printUsage method? > > > > Also, some refactoring is probably needed inside BabeldocCommand class. > > There are few things that I don't like right now: > > 1. This should be abstract class, right? Making BabeldocCommand instance > > does not make a sence. > > 2. We should not expect that subclasses will call super implementation when > > overide some method. For example in current implementation, subclass should > > call super.execute() when overriding execute() method. Better solution > > would be "Don't call me - I'll call you!" (Hollywood) principle. That is, > > BabeldocCommand should have one method, for example > > executeBabeldocCommand() that should call abstract execute() method. That > > way, subclass will be forced to implement execute(), and it should not > > worry about super implementation if it does not need to change default > > behaviour. > > 3. We should make all methods that subclasses need to implement abstract. > > That way we can make sure that it will be implemented. > > > > What do you think about this? I think it is quite easy to change this, but > > since many classes extend this class we need to agree with it! > > > > Dejan > > > > > > ----- Original Message ----- > > From: "David Glick" <dg...@co...> > > To: <bab...@li...> > > Sent: Wednesday, August 06, 2003 2:46 AM > > Subject: [Babeldoc-devel] Scanner tool and '-h' option? > > > > > It's normal for a program that prints a help screen to end so that it can > > > > be > > > > > re-run with options. The process tool, for example, does this, but the > > > scanner tool will print the help options and then continue to execute. > > > Is this the intended functionality? If not, I'd be happy to change it, > > > > because > > > > > it's driving me slightly batty... :-) > > > > > > > > > David > > > > > > -- > > > David Glick > > > Transmit Consulting, Inc > > > 619-475-4052 > > > dg...@tr... > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > > Data Reports, E-commerce, Portals, and Forums are available now. > > > Download today and enter to win an XBOX or Visual Studio .NET. > > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > > > > _______________________________________________ > > > Babeldoc-devel mailing list > > > Bab...@li... > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are available now. > > Download today and enter to win an XBOX or Visual Studio .NET. > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > _______________________________________________ > > Babeldoc-devel mailing list > > Bab...@li... > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > -- > David Glick > Transmit Consulting, Inc > 619-475-4052 > dg...@tr... > |
|
From: David G. <dg...@co...> - 2003-08-06 12:54:27
|
That service/query.properties file is a great source of information about how the system operates. Based on the name alone, I didn't pay any attention to it previously. I guess I'll spend some time with it now... :-) Thanks! On Wednesday 06 August 2003 5:37 am, Dejan Krsmanovic wrote: > Hi David! > > > Hi Dejan, > > > > My opinion is to avoid multiple exit points in programs where possible, > > even > > > though this is a trivial case and probably won't make much of an impact. > > As > > > an alternative, what about throwing an ApplicationExit() exception that > > can > > > be caught by BabeldocCommand to exit? If you think this is overly > > complicated, then I'm fine with System.exit() in printUsage(). > > I would not use exceptions in this case. In fact I think if we apply idea > that I suggested (abstract method and Holywood principle) there will be no > need for mutiple exit points, too. > > > I also agree that the current classes that extend BabeldocCommand should > > be > > > refactored; I've discovered at least one side effect that is causing > > problems > > > in Scanner, and will probably lead to further problems elsewhere in the > > future. > > > > Responding to your questions with questions of my own: > > > > 1. I'm not yet very familiar with the structure of the program, but if > > BabeldocCommand is made abstract, what happens when the user types > > "babeldoc > > > -h" ? In this instance (heh, heh), will a BabeldocCommand class be > > instantiated? > > Hmm. Try it ;) > Anyway enrty point in program is com.babeldoc.core.Main class and it will > make instance based on provided argument and appropriate class. Mapping > between program argument and command classes can be found in > service/query.properties file. So, BabeldocCommand cannot be instantiated > since it does not exist in this mapping! > > > 2. I agree with this point. It seems that the purpose of the current > > implementation is to perform some common pre-processing for all the > > tools, and I think that it would be relatively easy to restructure things > > so that the 'Hollywood Principle" applies (this principle, as detailed by > > the > > great > > > and wise Dejan Krsmanovic in his excellent programming book "How Your > > Lousy > > > Programming Is Helping Me Retire to a Life of Sin and Decadence", > > describes > > > some of the fundamental reasons that he's rich and we're not). > > Can you send me pdf version of that book, please! ;) > > Dejan > > > 3. I think this is generally good programming practice, and makes it much > > easier for those trying to understand the implementation of the system > > (i.e. > > > me). > > > > > > David > > > > On Wednesday 06 August 2003 2:27 am, Dejan Krsmanovic wrote: > > > After looking at code you have commited I doubt if this is really good > > > solution... Since h option belongs to parrent class, BabeldocCommand, I > > > guess that class is right place for handling this situation, otherwise, > > all > > > > other commands might need dealing with it. So, what do you think about > > > having System.exit call inside printUsage method? > > > > > > Also, some refactoring is probably needed inside BabeldocCommand class. > > > There are few things that I don't like right now: > > > 1. This should be abstract class, right? Making BabeldocCommand > > > instance does not make a sence. > > > 2. We should not expect that subclasses will call super implementation > > when > > > > overide some method. For example in current implementation, subclass > > should > > > > call super.execute() when overriding execute() method. Better solution > > > would be "Don't call me - I'll call you!" (Hollywood) principle. That > > is, > > > > BabeldocCommand should have one method, for example > > > executeBabeldocCommand() that should call abstract execute() method. > > That > > > > way, subclass will be forced to implement execute(), and it should not > > > worry about super implementation if it does not need to change default > > > behaviour. > > > 3. We should make all methods that subclasses need to implement > > abstract. > > > > That way we can make sure that it will be implemented. > > > > > > What do you think about this? I think it is quite easy to change this, > > but > > > > since many classes extend this class we need to agree with it! > > > > > > Dejan > > > > > > > > > ----- Original Message ----- > > > From: "David Glick" <dg...@co...> > > > To: <bab...@li...> > > > Sent: Wednesday, August 06, 2003 2:46 AM > > > Subject: [Babeldoc-devel] Scanner tool and '-h' option? > > > > > > > It's normal for a program that prints a help screen to end so that it > > can > > > > be > > > > > > > re-run with options. The process tool, for example, does this, but > > the > > > > > scanner tool will print the help options and then continue to > > > > execute. Is this the intended functionality? If not, I'd be happy to > > > > change > > it, > > > > because > > > > > > > it's driving me slightly batty... :-) > > > > > > > > > > > > David > > > > > > > > -- > > > > David Glick > > > > Transmit Consulting, Inc > > > > 619-475-4052 > > > > dg...@tr... > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email sponsored by: Free pre-built ASP.NET sites > > > > including Data Reports, E-commerce, Portals, and Forums are available > > > > now. Download today and enter to win an XBOX or Visual Studio .NET. > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > > > > _______________________________________________ > > > > Babeldoc-devel mailing list > > > > Bab...@li... > > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > > Data Reports, E-commerce, Portals, and Forums are available now. > > > Download today and enter to win an XBOX or Visual Studio .NET. > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > > > _______________________________________________ > > > Babeldoc-devel mailing list > > > Bab...@li... > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > -- > > David Glick > > Transmit Consulting, Inc > > 619-475-4052 > > dg...@tr... > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel -- David Glick Transmit Consulting, Inc 619-475-4052 dg...@tr... |
|
From: Dejan K. <dej...@nb...> - 2003-08-06 12:59:29
|
Note that every module can have its own service/query.properties file. So scanner workers are not defined in service/config.properties of core module but in scanner module. These file are merged together in runtime Dejan ----- Original Message ----- From: "David Glick" <dg...@co...> To: <bab...@li...> Sent: Wednesday, August 06, 2003 3:05 PM Subject: Re: [Babeldoc-devel] Scanner tool and '-h' option? > That service/query.properties file is a great source of information about how > the system operates. Based on the name alone, I didn't pay any attention to > it previously. I guess I'll spend some time with it now... :-) Thanks! > > On Wednesday 06 August 2003 5:37 am, Dejan Krsmanovic wrote: > > Hi David! > > > > > Hi Dejan, > > > > > > My opinion is to avoid multiple exit points in programs where possible, > > > > even > > > > > though this is a trivial case and probably won't make much of an impact. > > > > As > > > > > an alternative, what about throwing an ApplicationExit() exception that > > > > can > > > > > be caught by BabeldocCommand to exit? If you think this is overly > > > complicated, then I'm fine with System.exit() in printUsage(). > > > > I would not use exceptions in this case. In fact I think if we apply idea > > that I suggested (abstract method and Holywood principle) there will be no > > need for mutiple exit points, too. > > > > > I also agree that the current classes that extend BabeldocCommand should > > > > be > > > > > refactored; I've discovered at least one side effect that is causing > > > > problems > > > > > in Scanner, and will probably lead to further problems elsewhere in the > > > future. > > > > > > Responding to your questions with questions of my own: > > > > > > 1. I'm not yet very familiar with the structure of the program, but if > > > BabeldocCommand is made abstract, what happens when the user types > > > > "babeldoc > > > > > -h" ? In this instance (heh, heh), will a BabeldocCommand class be > > > instantiated? > > > > Hmm. Try it ;) > > Anyway enrty point in program is com.babeldoc.core.Main class and it will > > make instance based on provided argument and appropriate class. Mapping > > between program argument and command classes can be found in > > service/query.properties file. So, BabeldocCommand cannot be instantiated > > since it does not exist in this mapping! > > > > > 2. I agree with this point. It seems that the purpose of the current > > > implementation is to perform some common pre-processing for all the > > > tools, and I think that it would be relatively easy to restructure things > > > so that the 'Hollywood Principle" applies (this principle, as detailed by > > > the > > > > great > > > > > and wise Dejan Krsmanovic in his excellent programming book "How Your > > > > Lousy > > > > > Programming Is Helping Me Retire to a Life of Sin and Decadence", > > > > describes > > > > > some of the fundamental reasons that he's rich and we're not). > > > > Can you send me pdf version of that book, please! ;) > > > > Dejan > > > > > 3. I think this is generally good programming practice, and makes it much > > > easier for those trying to understand the implementation of the system > > > > (i.e. > > > > > me). > > > > > > > > > David > > > > > > On Wednesday 06 August 2003 2:27 am, Dejan Krsmanovic wrote: > > > > After looking at code you have commited I doubt if this is really good > > > > solution... Since h option belongs to parrent class, BabeldocCommand, I > > > > guess that class is right place for handling this situation, otherwise, > > > > all > > > > > > other commands might need dealing with it. So, what do you think about > > > > having System.exit call inside printUsage method? > > > > > > > > Also, some refactoring is probably needed inside BabeldocCommand class. > > > > There are few things that I don't like right now: > > > > 1. This should be abstract class, right? Making BabeldocCommand > > > > instance does not make a sence. > > > > 2. We should not expect that subclasses will call super implementation > > > > when > > > > > > overide some method. For example in current implementation, subclass > > > > should > > > > > > call super.execute() when overriding execute() method. Better solution > > > > would be "Don't call me - I'll call you!" (Hollywood) principle. That > > > > is, > > > > > > BabeldocCommand should have one method, for example > > > > executeBabeldocCommand() that should call abstract execute() method. > > > > That > > > > > > way, subclass will be forced to implement execute(), and it should not > > > > worry about super implementation if it does not need to change default > > > > behaviour. > > > > 3. We should make all methods that subclasses need to implement > > > > abstract. > > > > > > That way we can make sure that it will be implemented. > > > > > > > > What do you think about this? I think it is quite easy to change this, > > > > but > > > > > > since many classes extend this class we need to agree with it! > > > > > > > > Dejan > > > > > > > > > > > > ----- Original Message ----- > > > > From: "David Glick" <dg...@co...> > > > > To: <bab...@li...> > > > > Sent: Wednesday, August 06, 2003 2:46 AM > > > > Subject: [Babeldoc-devel] Scanner tool and '-h' option? > > > > > > > > > It's normal for a program that prints a help screen to end so that it > > > > can > > > > > > be > > > > > > > > > re-run with options. The process tool, for example, does this, but > > > > the > > > > > > > scanner tool will print the help options and then continue to > > > > > execute. Is this the intended functionality? If not, I'd be happy to > > > > > change > > > > it, > > > > > > because > > > > > > > > > it's driving me slightly batty... :-) > > > > > > > > > > > > > > > David > > > > > > > > > > -- > > > > > David Glick > > > > > Transmit Consulting, Inc > > > > > 619-475-4052 > > > > > dg...@tr... > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.Net email sponsored by: Free pre-built ASP.NET sites > > > > > including Data Reports, E-commerce, Portals, and Forums are available > > > > > now. Download today and enter to win an XBOX or Visual Studio .NET. > > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > > > > > > _______________________________________________ > > > > > Babeldoc-devel mailing list > > > > > Bab...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > > > Data Reports, E-commerce, Portals, and Forums are available now. > > > > Download today and enter to win an XBOX or Visual Studio .NET. > > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > > > > > _______________________________________________ > > > > Babeldoc-devel mailing list > > > > Bab...@li... > > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > > > -- > > > David Glick > > > Transmit Consulting, Inc > > > 619-475-4052 > > > dg...@tr... > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are available now. > > Download today and enter to win an XBOX or Visual Studio .NET. > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > _______________________________________________ > > Babeldoc-devel mailing list > > Bab...@li... > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > -- > David Glick > Transmit Consulting, Inc > 619-475-4052 > dg...@tr... > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel |
Thanks for helping keep SourceForge clean.
X