Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2076 closed defect (fixed)

simulation command-line arguments have changed

Reported by: janssen Owned by: lochel
Priority: normal Milestone: 1.9.0
Component: Backend Version: trunk
Keywords: Cc: lochel

Description

Until recently (1.9.0b3) the generated C simulation programs could be run with "-f FILENAME" and "-r FILENAME". Suddenly in the trunk those command line switches have changed (after years) to be "-f=FILENAME" and "-r=FILENAME". This has broken downstream code, without warning. Please either revert the command-line flags to the previous behavior, or explain why the change is necessary.

Change History (11)

comment:1 Changed 12 years ago by lochel

The command line flags for the simulation has been changed to provide better warnings. The old implementation did not recognized unknown flags or flag-values. If a user has misspellings in his flags, the simulation just ignored that flags without any warning.
Also the usage of the different flag types was not consistent.

Now we have 3 different flag-types:

  1. Flags without any value (e.g. –cpu)
  2. Flags with values (e.g. –lv=LOG_EVENTS,LOG_STATS)
  3. Flags with overwritings (e.g. –override var1=start1,startTime=val1)

comment:2 Changed 12 years ago by lochel

  • Cc lochel added

comment:3 Changed 12 years ago by janssen

So, why isn't "-override" now "-override=VALUES"? I don't think this is really consistent, so given that you're breaking a long-standing API with these changes, I think making the changes is on balance doing damage to your user community.

comment:4 Changed 12 years ago by lochel

You mean something like "–override=var1=start1,startTime=val1" That looks quite strange and would not be very intuitive/user-friendly.

comment:5 Changed 12 years ago by janssen

That's exactly what I mean. Right now you've got a mix of "-f VALUE", "-f=VALUE", and "-f", which is hard for people to remember. But if you don't like my suggestion for -override, what I actually prefer is this: go back to having just two consistent forms: "-f" and "-f VALUE". That way, "-r FOO" and "-override A=B,C=D" both follow the same rules.

comment:6 Changed 12 years ago by janssen

But please fix 2077 first!

comment:7 Changed 12 years ago by sjoelund.se

Lennart, why don't we simply allow both types of input? It's not that hard to validate that input.
-r FOO and -r=FOO could both be allowed and everyone will be happy.

comment:8 Changed 12 years ago by lochel

  • Owner changed from probably noone to lochel
  • Status changed from new to assigned

I already had the same idea to make everyone happy. I will implement it.

comment:9 Changed 12 years ago by adrpo

As far as I know all the flags were changed to
-flag=something, including override and overrideFile,
so that usage is homogeneous.

Yes, it would be good to provide either way with
-flag=something or -flag something (more natural
to users).

I think that not so many people are using the generated
executable directly and the changes to the programs that
start these are minimal (an = instead of a space).
Maybe is just a annoyance that we break the backwards
compatibility on this, but no more than that.

comment:10 Changed 12 years ago by lochel

  • Resolution set to fixed
  • Status changed from assigned to closed

No, the flags were changes to what I wrote in the beginning (3 types). But I guess even that was quite homogeneous. It should be comprehensible to use different notations for different flag-types.
Anyway, I have changed it in r15275 to make everyone happy. Now we can either use <-f=value> and <-f value>.

comment:11 Changed 12 years ago by janssen

OK, great! Thanks.

Note: See TracTickets for help on using tickets.