jargp-general Mailing List for JArgp Command Line Argument Processor
Brought to you by:
dsosnoski
Menu
▾
▴
jargp-general — General discussions on JArgp
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(8) |
Feb
|
Mar
(10) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brian H. <bri...@ac...> - 2005-03-18 12:36:51
|
Dude patch is there. I uploaded it before your last email. The problem with what you propose here is that I cannot do the following: command arg1 -m arg2 Jargp will die on arg1 and has done nothing for me. Brian Matthew Weigel wrote: > Brian Hawkins wrote: > >> You have not updated your project have you. StringListDef.java >> handles multiple occurrences of the same flag and places them in a >> List object. > > > > For some reason I believed sf.net when the site claimed "0 commits" > :-) I didn't think JArgP used the CVS... > > OK, so I'm looking back over how you described it working... I don't > like it. > > One of the stated operational mechanisms is that once JArgP hits > something that it doesn't expect/can't parse, it's done; the user can > snarf additional arguments at the end, by order. > > What you want can be accomplished pretty easily outside JArgP, by > depending on that behavior. > > Maybe the other developers disagree, but in any case, I think it would > be best served by showing a patch :-) |
|
From: Matthew W. <un...@id...> - 2005-03-18 06:04:24
|
Brian Hawkins wrote: > You have not updated your project have you. StringListDef.java > handles multiple occurrences of the same flag and places them in a > List object. For some reason I believed sf.net when the site claimed "0 commits" :-) I didn't think JArgP used the CVS... OK, so I'm looking back over how you described it working... I don't like it. One of the stated operational mechanisms is that once JArgP hits something that it doesn't expect/can't parse, it's done; the user can snarf additional arguments at the end, by order. What you want can be accomplished pretty easily outside JArgP, by depending on that behavior. Maybe the other developers disagree, but in any case, I think it would be best served by showing a patch :-) -- Matthew Weigel |
|
From: Brian H. <bri...@ac...> - 2005-03-18 05:40:05
|
You have not updated your project have you. StringListDef.java handles
multiple occurrences of the same flag and places them in a List object.
Brian
Matthew Weigel wrote:
> Brian Hawkins wrote:
>
>>
>>> I was actually planning on implementing something like that, but
>>> behaving differently - more like "foo -m arg1 -m arg2 -m arg3" to
>>> generate an array of size three.
>>>
>>> I'd prefer to discuss which approach is better (or if supporting
>>> both is reasonable) first.
>>
>>
>>
>> Not sure what you mean here. The code currently in CVS supports
>> multiple flags. Currently I can do "foo -m arg1 -m arg2 -m arg3",
>> but what I cannot do is "foo -m arg1 -m arg2 arg3 arg4". That is
>> until I made my changes. The code places the arguments in a List
>> object.
>
>
>
> I think what you're describing is "foo -a arg1 -b arg2 -c arg3...".
> I'm talking about being able to specify the same control argument
> ("-m") multiple times, with multple value arguments, and getting it
> all collected into an array whose name is associated with the "-m"
> control argument.
>
> To me, that seems more like typical use than "-m arg1 arg2 arg3",
> while also more readable.
|
|
From: Matthew W. <un...@id...> - 2005-03-18 05:36:01
|
Brian Hawkins wrote:
>
>> I was actually planning on implementing something like that, but
>> behaving differently - more like "foo -m arg1 -m arg2 -m arg3" to
>> generate an array of size three.
>>
>> I'd prefer to discuss which approach is better (or if supporting both
>> is reasonable) first.
>
>
> Not sure what you mean here. The code currently in CVS supports
> multiple flags. Currently I can do "foo -m arg1 -m arg2 -m arg3", but
> what I cannot do is "foo -m arg1 -m arg2 arg3 arg4". That is until I
> made my changes. The code places the arguments in a List object.
I think what you're describing is "foo -a arg1 -b arg2 -c arg3...". I'm
talking about being able to specify the same control argument ("-m")
multiple times, with multple value arguments, and getting it all
collected into an array whose name is associated with the "-m" control
argument.
To me, that seems more like typical use than "-m arg1 arg2 arg3", while
also more readable.
--
Matthew Weigel
|
|
From: Brian H. <bri...@ac...> - 2005-03-18 05:13:29
|
> I was actually planning on implementing something like that, but > behaving differently - more like "foo -m arg1 -m arg2 -m arg3" to > generate an array of size three. > > I'd prefer to discuss which approach is better (or if supporting both > is reasonable) first. Not sure what you mean here. The code currently in CVS supports multiple flags. Currently I can do "foo -m arg1 -m arg2 -m arg3", but what I cannot do is "foo -m arg1 -m arg2 arg3 arg4". That is until I made my changes. The code places the arguments in a List object. Brian |
|
From: Brian H. <bri...@ac...> - 2005-03-18 04:36:48
|
How do you want the patch? Should I just upload the modified files? >> would like to fix is the way it handles number options. The number >> must be right next to the flag "-t2" works but "-t 2" does not. > > > Given that JArgP is in use 'in the wild,' I think that changing the > behavior would be a very bad thing. I'm not talking about changing the behavior I'm talking about fixing it. If I assign -t as a numeric option and I put "-t 2" on the command line I get an error. What I'm saying is that it should be fixed so I could do "-t2" and "-t 2". The fix would be relatively simple. Just check for and eat up the white space before parsing the number. Brian |
|
From: Matthew W. <un...@id...> - 2005-03-18 00:20:18
|
Brian Hawkins wrote: > I was able to do this with very few changes to the system. I created a > new class that extended StringListDef called NoFlagArgDef and the flag > for it is ' '. (an empty space). Then when the ArgumentProcessor hits > an option that has no flag it pretends it is the ' ' flag. It works > really good. How do you want the changes I've made? Oh, that's right. I was actually planning on implementing something like that, but behaving differently - more like "foo -m arg1 -m arg2 -m arg3" to generate an array of size three. I'd prefer to discuss which approach is better (or if supporting both is reasonable) first. Why don't you upload a patch for now? > would like to fix is the way it handles number options. The number must > be right next to the flag "-t2" works but "-t 2" does not. Given that JArgP is in use 'in the wild,' I think that changing the behavior would be a very bad thing. -- Matthew Weigel |
|
From: Brian H. <bri...@ac...> - 2005-03-17 23:50:28
|
From an email I posted a couple of months ago: I have a project where I can get several items on the command line after the flagged options. For example -v -t 1 -d on task1 task2 task3 What I wanted to do was have a list variable receive the values task1, task2 and task3. I was able to do this with very few changes to the system. I created a new class that extended StringListDef called NoFlagArgDef and the flag for it is ' '. (an empty space). Then when the ArgumentProcessor hits an option that has no flag it pretends it is the ' ' flag. It works really good. How do you want the changes I've made? For now I've just made the changes and build them locally but I would like to get it back into the project. Another one that bugs me that I would like to fix is the way it handles number options. The number must be right next to the flag "-t2" works but "-t 2" does not. Brian Matthew Weigel wrote: > Brian Hawkins wrote: > >> Is there anyone maintaining this project? I've got some improvements >> I'd like to see get in. > > > I'm here, and still putting some effort into the changes I last > discussed on this list. > > Apropos that (being able to use ArgumentProcessor to apply to more > than one object, each object having a different ParameterSet), I think > I hit upon a superior solution just last night. > > But I'll talk about that later... what improvements? |
|
From: Matthew W. <un...@id...> - 2005-03-17 19:40:11
|
Brian Hawkins wrote: > Is there anyone maintaining this project? I've got some improvements > I'd like to see get in. I'm here, and still putting some effort into the changes I last discussed on this list. Apropos that (being able to use ArgumentProcessor to apply to more than one object, each object having a different ParameterSet), I think I hit upon a superior solution just last night. But I'll talk about that later... what improvements? -- Matthew Weigel |
|
From: Brian H. <bri...@ac...> - 2005-03-17 18:26:34
|
Is there anyone maintaining this project? I've got some improvements I'd like to see get in. Brian |
|
From: Brian H. <bri...@ac...> - 2005-01-29 04:30:38
|
I have a project where I can get several items on the command line after the flagged options. For example -v -t 1 -d on task1 task2 task3 What I wanted to do was have a list variable receive the values task1, task2 and task3. I was able to do this with very few changes to the system. I created a new class that extended StringListDef called NoFlagArgDef and the flag for it is ' '. (an empty space). Then when the ArgumentProcessor hits an option that has no flag it pretends it is the ' ' flag. It works really good. How do you want the changes I've made? Brian |
|
From: Matthew W. <un...@id...> - 2005-01-10 22:57:35
|
(again, sorry for my difficulty using an email client and not sending it to the list for archival) Dennis Sosnoski said: > As far as next(false) goes, I really don't like the idea of skipping past arguments just so you can process the skipped ones later with a separate instance. That isn't the only reason. The other reason is that in 1.0, JArgP makes particular assumptions about where non-control arguments show up - they go at the end. JArgP just stops processing as soon as it hits something it doesn't recognize. If what it doesn't recognize is a control parameter, it throws an exception; if it isn't, JArgP silently stops. This behavior is only alluded to once, as far as I can tell, and isn't completely intuitive - I think that users would expect to be able to at least precede all control arguments with non-control arguments. However, if a user builds their command line like that (to borrow from your article on reflection, using the command line 'java PlanGen plan.txt -c -f2500 -g2.5 -n "iSue4U - Litigation at Internet Speed"'), then all the control arguments are lost. > I agree that the changes to supply a target per > ParameterSet might be messy... how about allowing one ArgumentProcessor to delegate to another one if it doesn't recognize a parameter? That sounds very reasonable. > This not only allows for multiple levels of argument > processing, it also allows you to split flag characters within a single "run" between the different ones, something that'd be very ugly otherwise. I'm not sure I follow you here. Could you illustrate? > You'd also need to make sure the StringTracker instance gets set on all the ArgumentProcessor instances for this to work properly, but that's just another simple added method (set the StringTracker instance and call same method on backup, if defined). I'll look into it. -- Matthew Weigel hacker un...@id... |
|
From: Dennis S. <dm...@so...> - 2005-01-10 21:54:47
|
Added you to the project. As far as next(false) goes, I really don't like the idea of skipping past arguments just so you can process the skipped ones later with a separate instance. I agree that the changes to supply a target per ParameterSet might be messy... how about allowing one ArgumentProcessor to delegate to another one if it doesn't recognize a parameter? That way, if you want to split processing between multiple argument lists you can set the optional backup ArgumentProcessor in your main one. This should also be very easy to implement - just factor out a processArgument method in ArgumentProcessor that takes the flag character. If it finds the flag character in its parameter set it just processes it directly; otherwise it calls the same method on the backup ArgumentProcessor. This not only allows for multiple levels of argument processing, it also allows you to split flag characters within a single "run" between the different ones, something that'd be very ugly otherwise. You'd also need to make sure the StringTracker instance gets set on all the ArgumentProcessor instances for this to work properly, but that's just another simple added method (set the StringTracker instance and call same method on backup, if defined). - Dennis Matthew Weigel wrote: > On 8 Jan, 2005, at 9:06 PM, Dennis Sosnoski wrote: > >> By the way, the StringTracker class already defines a peek() method >> which seems equivalent to your next(false). I'd prefer the peek() >> method to next(false), since the former seems more intuitive to me. > > > No, there's a pretty big difference. With peek(), you don't advance > the index, and with next(false), you do. All three functions - get a > value, advance, consume; get a value, advance; and just get a value - > are significant. I agree that the next(false) idiom is a poor one, > but I'm not sure what a better approach would be. > >> On the issue of initializing instances of two separate classes from >> the same set of argument values, I'm somewhat torn. This seems like a >> very specialized usage, and I don't know that it's a good idea to >> extend the operation to support it. If you really want to get this >> functionality, I'd think it'd be cleaner to do it by adding an >> optional target object per ParameterSet. > > > Interesting idea... but I *suspect* that that change will actually > require more significant changes to the code, and will constitute a > more serious design change for a very specialized usage :-) > >> I do like the idea of supporting gnu-style "--full-name" parameters, >> and think it should be an easy change to add this support. There've >> been several cases where I've been leaning toward this myself, after >> defining a dozen or so character parameter flags. And I do think the >> gnu-style with two leading hyphens is appropriate, since that way it >> doesn't interfere with the existing character parameter handling. > > > I think that is why GNU did it that way. > > By the way, my sourceforge ID is bsdcat. |
|
From: Matthew W. <un...@id...> - 2005-01-09 03:36:58
|
On 8 Jan, 2005, at 9:06 PM, Dennis Sosnoski wrote: > By the way, the StringTracker class already defines a peek() method > which seems equivalent to your next(false). I'd prefer the peek() > method to next(false), since the former seems more intuitive to me. No, there's a pretty big difference. With peek(), you don't advance the index, and with next(false), you do. All three functions - get a value, advance, consume; get a value, advance; and just get a value - are significant. I agree that the next(false) idiom is a poor one, but I'm not sure what a better approach would be. > On the issue of initializing instances of two separate classes from > the same set of argument values, I'm somewhat torn. This seems like a > very specialized usage, and I don't know that it's a good idea to > extend the operation to support it. If you really want to get this > functionality, I'd think it'd be cleaner to do it by adding an > optional target object per ParameterSet. Interesting idea... but I *suspect* that that change will actually require more significant changes to the code, and will constitute a more serious design change for a very specialized usage :-) > I do like the idea of supporting gnu-style "--full-name" parameters, > and think it should be an easy change to add this support. There've > been several cases where I've been leaning toward this myself, after > defining a dozen or so character parameter flags. And I do think the > gnu-style with two leading hyphens is appropriate, since that way it > doesn't interfere with the existing character parameter handling. I think that is why GNU did it that way. By the way, my sourceforge ID is bsdcat. -- Matthew Weigel unique&idempot.ent Unique and Idempotent |
|
From: Dennis S. <dm...@so...> - 2005-01-09 03:06:16
|
By the way, the StringTracker class already defines a peek() method which seems equivalent to your next(false). I'd prefer the peek() method to next(false), since the former seems more intuitive to me. On the issue of initializing instances of two separate classes from the same set of argument values, I'm somewhat torn. This seems like a very specialized usage, and I don't know that it's a good idea to extend the operation to support it. If you really want to get this functionality, I'd think it'd be cleaner to do it by adding an optional target object per ParameterSet. ParameterSet already handles delegation to other parameter sets anyway, which allows for some parameters to be defined in a base class and other added by a subclass; extending it with a separate target object would just take this a step further while preserving the principle that arguments are processed in sequence and unknown arguments result in an error. I do like the idea of supporting gnu-style "--full-name" parameters, and think it should be an easy change to add this support. There've been several cases where I've been leaning toward this myself, after defining a dozen or so character parameter flags. And I do think the gnu-style with two leading hyphens is appropriate, since that way it doesn't interfere with the existing character parameter handling. - Dennis Dennis Sosnoski wrote: > Okay, I updated with the minor changes I've made over the last few > months (mainly just the added StringListDef for repeated string > parameters, as in your design issue list). I'll add you as a developer > and you can make your changes. What's your SourceForge user ID? > > One thing I've been considering is an active parameter type, which > would actually call out to user code at the time an argument is being > processed. This would be useful for loading a set of parameters from > an XML configuration file, for instance (which could then be > overridden by later command line parameters). > > - Dennis > > Matthew Weigel wrote: > >> (whoops, my mailer decided this shouldn't go to the list) >> >> Dennis Sosnoski said: >> >> >> >>> What kind of fixes have you made, and what kind of design issues have >>> >> >> you run into? >> >> Fixes: >> >> There were a few cut-and-paste errors in the JavaDoc that I fixed (i.e., >> the ParameterSet and ParameterDef[] constructors to ArgumentProcessor >> both >> refer to a ParameterDef[] argument). >> http://sourceforge.net/tracker/index.php?func=detail&aid=1091919&group_id=83036&atid=568105 >> >> >> I added the fix nickjohn requested, making ArgumentProcesser.setValue() >> public. I have not yet tested this, because I haven't created any new >> subclasses of ParameterDef outside org.jargp. >> http://sourceforge.net/tracker/index.php?func=detail&aid=1027737&group_id=83036&atid=568105 >> >> >> I added the change Rich Gibbs requested, so that it doesn't matter >> whether >> parameters are defined in the current class or a parent class. If I >> understand the issue correctly, I tested this with a subclass of a class >> that had parameters defined. >> http://sourceforge.net/tracker/index.php?func=detail&aid=838610&group_id=83036&atid=568106 >> >> >> I added the fix I mentioned for a bug in ParameterSet.indexDef(), which >> made it not actually work with more than one ParameterDef array. I >> tested >> this with a subclass of a class that had parameters defined, that added >> parameters using a ParameterSet. >> http://sourceforge.net/tracker/index.php?func=detail&aid=1089233&group_id=83036&atid=568105 >> >> >> I removed ArgumentProcessor.getIndex() because it is not ever used in >> the >> package, but it is restricted to package visibility. >> >> Design issues: >> >> The main one is that StringTracker implicitly consumes an argument when >> you invoke next(). The other is that ArgumentProcessor wants to assume >> that precisely one object will consume all control arguments. From one >> design perspective (strictly decoupling the class that gets input >> from the >> command line from all other classes) this is reasonable, but from >> another >> (spreading the convenience of command-line control as necessary) it's >> not. >> >> The major change I applied was to make StringTracker's consumption of >> values explicit; thus you can also explicitly avoid consuming an >> argument. >> I did this by adding a method, next(boolean isConsumed) and modifying >> next() to invoke next(true) so the old behavior is preserved. >> >> I also extended ArgumentProcessor to ignore control arguments it doesn't >> understand, by not consuming them. I accomplished this with additional >> logic, and creating a new method, processArgs(String[] args, Object >> target, boolean willFinish) where the last argument determines whether >> processArgs will assume that it must consume all control arguments or >> not >> (this method's return value is also String[], for the unconsumed >> arguments). I modified processArgs(String[] args, Object target) to >> call >> processArgs(args, target, true) (it still returns the target Object, and >> not a String[]). >> >> These design changes allowed me to use ArgumentProcessor in a new way, >> initializing instances of two different classes from the same >> String[] of >> arguments. ArgumentProcessor handles every control argument that >> applies >> to the first class, and returns a String[] of arguments that have not >> been >> consumed; I then pass this argument list, along with a different >> class and >> different ParameterSet, to a second instance of ArgumentProcessor and >> initialize a second object. >> >> Issues I haven't yet dealt with: >> >> The assumption that each control argument will be used only once. I'd >> like to support something like "-m foo -m bar" to populate an array with >> multiple values. >> >> The assumption that control arguments are of the form '-c'. I'd like to >> suppor strings, either of the form '-word' or '--gnu-style'. >> >> Looking through a diff, I also introduced a new cut-and-paste error >> in the >> JavaDoc, claiming that Object processArgs(String[] args, Object target) >> returns a String[] of unprocessed arguments. I've fixed it and I'll >> upload it when I have time. > |
|
From: Dennis S. <dm...@so...> - 2005-01-08 22:54:12
|
Okay, I updated with the minor changes I've made over the last few months (mainly just the added StringListDef for repeated string parameters, as in your design issue list). I'll add you as a developer and you can make your changes. What's your SourceForge user ID? One thing I've been considering is an active parameter type, which would actually call out to user code at the time an argument is being processed. This would be useful for loading a set of parameters from an XML configuration file, for instance (which could then be overridden by later command line parameters). - Dennis Matthew Weigel wrote: >(whoops, my mailer decided this shouldn't go to the list) > >Dennis Sosnoski said: > > > >>What kind of fixes have you made, and what kind of design issues have >> >> >you run into? > >Fixes: > >There were a few cut-and-paste errors in the JavaDoc that I fixed (i.e., >the ParameterSet and ParameterDef[] constructors to ArgumentProcessor both >refer to a ParameterDef[] argument). >http://sourceforge.net/tracker/index.php?func=detail&aid=1091919&group_id=83036&atid=568105 > >I added the fix nickjohn requested, making ArgumentProcesser.setValue() >public. I have not yet tested this, because I haven't created any new >subclasses of ParameterDef outside org.jargp. >http://sourceforge.net/tracker/index.php?func=detail&aid=1027737&group_id=83036&atid=568105 > >I added the change Rich Gibbs requested, so that it doesn't matter whether >parameters are defined in the current class or a parent class. If I >understand the issue correctly, I tested this with a subclass of a class >that had parameters defined. >http://sourceforge.net/tracker/index.php?func=detail&aid=838610&group_id=83036&atid=568106 > >I added the fix I mentioned for a bug in ParameterSet.indexDef(), which >made it not actually work with more than one ParameterDef array. I tested >this with a subclass of a class that had parameters defined, that added >parameters using a ParameterSet. >http://sourceforge.net/tracker/index.php?func=detail&aid=1089233&group_id=83036&atid=568105 > >I removed ArgumentProcessor.getIndex() because it is not ever used in the >package, but it is restricted to package visibility. > >Design issues: > >The main one is that StringTracker implicitly consumes an argument when >you invoke next(). The other is that ArgumentProcessor wants to assume >that precisely one object will consume all control arguments. From one >design perspective (strictly decoupling the class that gets input from the >command line from all other classes) this is reasonable, but from another >(spreading the convenience of command-line control as necessary) it's not. > >The major change I applied was to make StringTracker's consumption of >values explicit; thus you can also explicitly avoid consuming an argument. > I did this by adding a method, next(boolean isConsumed) and modifying >next() to invoke next(true) so the old behavior is preserved. > >I also extended ArgumentProcessor to ignore control arguments it doesn't >understand, by not consuming them. I accomplished this with additional >logic, and creating a new method, processArgs(String[] args, Object >target, boolean willFinish) where the last argument determines whether >processArgs will assume that it must consume all control arguments or not >(this method's return value is also String[], for the unconsumed >arguments). I modified processArgs(String[] args, Object target) to call >processArgs(args, target, true) (it still returns the target Object, and >not a String[]). > >These design changes allowed me to use ArgumentProcessor in a new way, >initializing instances of two different classes from the same String[] of >arguments. ArgumentProcessor handles every control argument that applies >to the first class, and returns a String[] of arguments that have not been >consumed; I then pass this argument list, along with a different class and >different ParameterSet, to a second instance of ArgumentProcessor and >initialize a second object. > >Issues I haven't yet dealt with: > >The assumption that each control argument will be used only once. I'd >like to support something like "-m foo -m bar" to populate an array with >multiple values. > >The assumption that control arguments are of the form '-c'. I'd like to >suppor strings, either of the form '-word' or '--gnu-style'. > >Looking through a diff, I also introduced a new cut-and-paste error in the >JavaDoc, claiming that Object processArgs(String[] args, Object target) >returns a String[] of unprocessed arguments. I've fixed it and I'll >upload it when I have time. > |
|
From: Matthew W. <un...@id...> - 2005-01-07 15:40:20
|
(whoops, my mailer decided this shouldn't go to the list) Dennis Sosnoski said: > What kind of fixes have you made, and what kind of design issues have you run into? Fixes: There were a few cut-and-paste errors in the JavaDoc that I fixed (i.e., the ParameterSet and ParameterDef[] constructors to ArgumentProcessor both refer to a ParameterDef[] argument). http://sourceforge.net/tracker/index.php?func=detail&aid=1091919&group_id=83036&atid=568105 I added the fix nickjohn requested, making ArgumentProcesser.setValue() public. I have not yet tested this, because I haven't created any new subclasses of ParameterDef outside org.jargp. http://sourceforge.net/tracker/index.php?func=detail&aid=1027737&group_id=83036&atid=568105 I added the change Rich Gibbs requested, so that it doesn't matter whether parameters are defined in the current class or a parent class. If I understand the issue correctly, I tested this with a subclass of a class that had parameters defined. http://sourceforge.net/tracker/index.php?func=detail&aid=838610&group_id=83036&atid=568106 I added the fix I mentioned for a bug in ParameterSet.indexDef(), which made it not actually work with more than one ParameterDef array. I tested this with a subclass of a class that had parameters defined, that added parameters using a ParameterSet. http://sourceforge.net/tracker/index.php?func=detail&aid=1089233&group_id=83036&atid=568105 I removed ArgumentProcessor.getIndex() because it is not ever used in the package, but it is restricted to package visibility. Design issues: The main one is that StringTracker implicitly consumes an argument when you invoke next(). The other is that ArgumentProcessor wants to assume that precisely one object will consume all control arguments. From one design perspective (strictly decoupling the class that gets input from the command line from all other classes) this is reasonable, but from another (spreading the convenience of command-line control as necessary) it's not. The major change I applied was to make StringTracker's consumption of values explicit; thus you can also explicitly avoid consuming an argument. I did this by adding a method, next(boolean isConsumed) and modifying next() to invoke next(true) so the old behavior is preserved. I also extended ArgumentProcessor to ignore control arguments it doesn't understand, by not consuming them. I accomplished this with additional logic, and creating a new method, processArgs(String[] args, Object target, boolean willFinish) where the last argument determines whether processArgs will assume that it must consume all control arguments or not (this method's return value is also String[], for the unconsumed arguments). I modified processArgs(String[] args, Object target) to call processArgs(args, target, true) (it still returns the target Object, and not a String[]). These design changes allowed me to use ArgumentProcessor in a new way, initializing instances of two different classes from the same String[] of arguments. ArgumentProcessor handles every control argument that applies to the first class, and returns a String[] of arguments that have not been consumed; I then pass this argument list, along with a different class and different ParameterSet, to a second instance of ArgumentProcessor and initialize a second object. Issues I haven't yet dealt with: The assumption that each control argument will be used only once. I'd like to support something like "-m foo -m bar" to populate an array with multiple values. The assumption that control arguments are of the form '-c'. I'd like to suppor strings, either of the form '-word' or '--gnu-style'. Looking through a diff, I also introduced a new cut-and-paste error in the JavaDoc, claiming that Object processArgs(String[] args, Object target) returns a String[] of unprocessed arguments. I've fixed it and I'll upload it when I have time. -- Matthew Weigel hacker un...@id... |
|
From: Dennis S. <dm...@so...> - 2005-01-07 09:21:22
|
Hi Matthew, Sorry for not replying in a reasonable time to the messages you sent directly to me. I'd love to see someone take over active development of Jargp. I've made some changes myself, to handle cases such as repeating parameters, but have too many other things going on to do another release of Jargp at present. What kind of fixes have you made, and what kind of design issues have you run into? Let's discuss them on this list so that it becomes part of the project record. If your changes look sound I'll add you as a developer and we can move forward on new release. Thanks for your interest! - Dennis Matthew Weigel wrote: >Well, I guess this is what makes SourceForge useful, right? You can >hijack a project on which no one is actually working by uploading >'patches.' > >I've found and fixed a number of bugs, and addressed a few design issues >that don't properly qualify as bugs, but no one has responded to my >efforts to discuss them. > >I had planned on putting out a bunch of patches in small, easily >digestable chunks based on the specific bugs fixed or issues addressed, >but that's a fair bit of work for me when no one is responding about >examining or incorporating them. > >So, as time permits, I'm going to work on simply uploading my current >working version as a 'patch,' along with a real jumbo diff against the >official 1.0 release so that it's clear what has been touched and not. > >If the developers are interested in incorporating these changes, let me >know. I wouldn't mind making a set of smaller, discrete patches for >individual perusal at all, but I don't see any point in keeping my >improvements away from people. > |
|
From: Matthew W. <un...@id...> - 2004-12-27 20:36:21
|
Well, I guess this is what makes SourceForge useful, right? You can hijack a project on which no one is actually working by uploading 'patches.' I've found and fixed a number of bugs, and addressed a few design issues that don't properly qualify as bugs, but no one has responded to my efforts to discuss them. I had planned on putting out a bunch of patches in small, easily digestable chunks based on the specific bugs fixed or issues addressed, but that's a fair bit of work for me when no one is responding about examining or incorporating them. So, as time permits, I'm going to work on simply uploading my current working version as a 'patch,' along with a real jumbo diff against the official 1.0 release so that it's clear what has been touched and not. If the developers are interested in incorporating these changes, let me know. I wouldn't mind making a set of smaller, discrete patches for individual perusal at all, but I don't see any point in keeping my improvements away from people. -- Matthew Weigel hacker un...@id... |
|
From: Matthew W. <un...@id...> - 2004-09-14 05:58:01
|
Howdy. I started taking a look at JArgP today, and in the short term it
does everything I need. But I thought I'd take a look inside anyway...
I *think* I've found a bug. I'm tired, and I haven't done Java
programming in forever, but it sure looks like a bug.
Line 164 in ArgumentProcessor.java can end it all before a single argument
has been processed, even if there are arguments coming down the pipe:
You get to that line if
m_currentArg.hasNext()
is false, and
m_remainingArgs.hasNext()
is true, and
next.length() > 0 && next.charAt(0) == '-'
is false.
More succinctly, "next.length() > 0" could evaluate to true, but if that
first argument is not a control flag, nothing is processed. Is the
assumption simply that non-control arguments must come last? That seems
moderately bogus to me in an argument-processing library where it's
difficult to make assumptions about the command line interface.
I came across this as I delved into the code trying to add long arguments in
the GNU style ('--foo' and/or '--foo bar' and/or '--foo=bar'). I think I'll
also look into being able to specify a control flag more than once (like
'-m onefile -m anotherfile -m thirdfile') and have it load values into an
array, but I figured this would be the easier first step.
--
Matthew Weigel
hacker
un...@id...
|
|
From: Tauzell, D. <Dav...@Rx...> - 2004-05-26 14:47:16
|
Hi Dennis, My sourceforge account is 'tauzell'. I'm quite busy at the moment, but I'll find some time to make the updates. I can add DateDef and FileDef definitions too. They are quite simple and don't add any external dependencies. -Dave -----Original Message----- From: Dennis Sosnoski [mailto:dm...@so...]=20 Sent: Monday, May 24, 2004 11:24 AM To: Tauzell, Dave Cc: jar...@li... Subject: Re: [Jargp-general] Creating new Def classes Hi Dave, I noticed I hadn't responded to this on-list. I think the scope change=20 is absolutely the correct thing to do. If you want to make the change=20 just email me directly with your SourceForge account name and I'll add=20 you as a developer so you can do this. The DateDef and FileDef classes also sound interesting. I'd think any=20 parameter type extensions that don't add too much additional code should be fine. I'd prefer to see the core library kept reasonably small just=20 to make sure it doesn't become unwieldly. Several other developers have expressed interest in extending Jargp.=20 I've suggested they hold discussions on this list to arrive at a=20 concensus, but so far I haven't seen anything going on. - Dennis Tauzell, Dave wrote: > Hi, > =20 > I created two new Def classes DateDef and FileDef. If I put them into > my own package I run into a problem calling the=20 > ArguementProcessor.setSave() method because it is marked as package=20 > scope. There is no other way to get at the target object to set the=20 > value. > =20 > Can you change the scope of setValue()? Are you interested in any new > Def classes? > =20 > Thanks, > Dave |
|
From: <ben...@id...> - 2004-05-25 09:19:05
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Dennis S. <dm...@so...> - 2004-05-24 16:24:14
|
Hi Dave, I noticed I hadn't responded to this on-list. I think the scope change is absolutely the correct thing to do. If you want to make the change just email me directly with your SourceForge account name and I'll add you as a developer so you can do this. The DateDef and FileDef classes also sound interesting. I'd think any parameter type extensions that don't add too much additional code should be fine. I'd prefer to see the core library kept reasonably small just to make sure it doesn't become unwieldly. Several other developers have expressed interest in extending Jargp. I've suggested they hold discussions on this list to arrive at a concensus, but so far I haven't seen anything going on. - Dennis Tauzell, Dave wrote: > Hi, > > I created two new Def classes DateDef and FileDef. If I put them into > my own package I run into a problem calling the > ArguementProcessor.setSave() method because it is marked as package > scope. There is no other way to get at the target object to set the > value. > > Can you change the scope of setValue()? Are you interested in any new > Def classes? > > Thanks, > Dave |
|
From: Tauzell, D. <Dav...@Rx...> - 2004-05-07 15:23:36
|
Hi,
=20
I created two new Def classes DateDef and FileDef. If I put them into
my own package I run into a problem calling the
ArguementProcessor.setSave() method because it is marked as package
scope. There is no other way to get at the target object to set the
value.
=20
Can you change the scope of setValue()? Are you interested in any new
Def classes?
=20
Thanks,
Dave
|
