Just realised that my options parser isn't publically available, which I have just remedied.

What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?

On Wed, 26 Jul 2023 08:34:57 -0700, Malcolm McLean wrote:

> Just realised that my options parser isn't publically available,
> which I have just remedied.
>
> What approaches do people use towards parsing commandline
> options? Do you use getopt() ? Or do you find that real world
> programs have a simple enough set of options that it's easier
> to write bespoke code?

For simple commandlines, I usually write my own argument
"parser" (typically a set of strcmp() calls). For more complex
commandlines, I stick with getopt().

I haven't found any commandlines yet that require lex&yacc, but
I still keep looking for them (yes, I like the challenge :-) )

--
Lew Pitcher
"In Skills We Trust"

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>Just realised that my options parser isn't publically available, which I have just remedied.
>
>What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?

getopt. always.

On Wed, 26 Jul 2023 08:34:57 -0700 (PDT) Malcolm McLean
<malcolm.arthur.mclean@gmail.com> wrote:
> Just realised that my options parser isn't publically available, which I
> have just remedied.
>
> What approaches do people use towards parsing commandline options ? Do you
> use getopt() ? Or do you find that real world programs have a simple enough
> set of options that it's easier to write bespoke code?

Custom made. Nothing fancy , never needed it.

In article <a631f98c-5482-4e90-9a0d-8ce49e447153n@googlegroups.com>,
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>Just realised that my options parser isn't publically available, which
>I have just remedied.

URL?

--
I shot a man on Fifth Aveneue, just to see him die.

On Wednesday, 26 July 2023 at 17:23:11 UTC+1, Kenny McCormack wrote:
> In article <a631f98c-5482-4e90...@googlegroups.com>,
> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> >Just realised that my options parser isn't publically available, which
> >I have just remedied.
> URL?
>
https://github.com/MalcolmMcLean/optionparser
>
But I's like a discussion about what people would like to see in an options parser
rather than focusing too much on the specifics of my code in the first instance.

On 7/26/2023 10:34 AM, Malcolm McLean wrote:
> Just realised that my options parser isn't publically available, which I have just remedied.
>
> What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?

And what do you do about Unicode on your command line ?

Lynn

On 7/26/2023 5:28 PM, Lynn McGuire wrote:
> On 7/26/2023 10:34 AM, Malcolm McLean wrote:
>> Just realised that my options parser isn't publically available, which
>> I have just remedied.
>>
>> What approaches do people use towards parsing commandline options ? Do
>> you use getopt() ? Or do you find that real world programs have a
>> simple enough set of options that it's easier to write bespoke code?
>
> And what do you do about Unicode on your command line ?
>
> Lynn

BTW, we rolled our own command line parser that handles Unicode.

Lynn

On 2023-07-26, Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> On 7/26/2023 10:34 AM, Malcolm McLean wrote:
>> Just realised that my options parser isn't publically available, which I have just remedied.
>>
>> What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?
>
> And what do you do about Unicode on your command line ?

That's just another UTF-8 input; same as from a text stream.

$ txr -e '(put-line "日本語")'
日本語

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 7/26/23 11:34, Malcolm McLean wrote:
> Just realised that my options parser isn't publically available, which I have just remedied.
>
> What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?
​I've only written one program where i had to deal with command-line
options, and when that happened i just used getopt(). That being said,
were i to write any more programs like that i don't think i'd use it, in
part because i think that the paradigm of the option is wantonly applied
to every program without consideration for whether it's most optimal
because it's just what everyone is used to.
--
⚗︎ | /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
Bitches stole my whole ass ␔🭖᷿᪳𝼗᷍⏧𒒫𐻾ࣛ↉�⃣ quoted-printable, can't
have shit in Thunderbird 😩

On Thursday, 27 July 2023 at 09:00:26 UTC+1, Blue-Maned_Hawk wrote:
> On 7/26/23 11:34, Malcolm McLean wrote:
> > Just realised that my options parser isn't publically available, which I have just remedied.
> >
> > What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?
> ​I've only written one program where i had to deal with command-line
> options, and when that happened i just used getopt(). That being said,
> were i to write any more programs like that i don't think i'd use it, in
> part because i think that the paradigm of the option is wantonly applied
> to every program without consideration for whether it's most optimal
> because it's just what everyone is used to.
>
I don't write commandline programs at work. Whilst I can imagine circumstances
in which that changed, a utility would most likely be in Python. For hobby programs,
it's also rare to need many options.

On Wednesday, 26 July 2023 at 23:45:06 UTC+1, Lynn McGuire wrote:
> On 7/26/2023 5:28 PM, Lynn McGuire wrote:
> > On 7/26/2023 10:34 AM, Malcolm McLean wrote:
> >> Just realised that my options parser isn't publically available, which
> >> I have just remedied.
> >>
> >> What approaches do people use towards parsing commandline options ? Do
> >> you use getopt() ? Or do you find that real world programs have a
> >> simple enough set of options that it's easier to write bespoke code?
> >
> > And what do you do about Unicode on your command line ?
> >
> > Lynn
> BTW, we rolled our own command line parser that handles Unicode.
>
You'd need to tweak the options parser slightly because it has a concept of
single character flags (so the user types something like "tar -xvf file.tar" he's
not passing one option "xvf", but three flags). So it would have to be UTF-8
aware to accomodate Unicode flags. Long options should work tranparently.
It's maybe a worthwhile change.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Wednesday, 26 July 2023 at 23:45:06 UTC+1, Lynn McGuire wrote:
>> On 7/26/2023 5:28 PM, Lynn McGuire wrote:
>> > On 7/26/2023 10:34 AM, Malcolm McLean wrote:
>> >> Just realised that my options parser isn't publically available, which
>> >> I have just remedied.
>> >>
>> >> What approaches do people use towards parsing commandline options ? Do
>> >> you use getopt() ? Or do you find that real world programs have a
>> >> simple enough set of options that it's easier to write bespoke code?
>> >
>> > And what do you do about Unicode on your command line ?
>> >
>> > Lynn
>> BTW, we rolled our own command line parser that handles Unicode.
>>
> You'd need to tweak the options parser slightly because it has a
> concept of single character flags (so the user types something like
> "tar -xvf file.tar" he's not passing one option "xvf", but three
> flags). So it would have to be UTF-8 aware to accomodate Unicode
> flags. Long options should work tranparently. It's maybe a worthwhile
> change.

I've never seen an option name that uses non-ASCII characters. The vast
majority of option names use just letters, mostly lowercase --
sometimes digits, and hyphens or rarely underscores for long option
names.

Handling full UTF-8 for *arguments* to options is useful. Requiring
non-ASCII characters as option names is going to make commands difficult
to type for a lot of users.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Blue-Maned_Hawk <bluemanedhawk@gmail.com> writes:
> On 7/26/23 11:34, Malcolm McLean wrote:
>> Just realised that my options parser isn't publically available,
>> which I have just remedied. What approaches do people use towards
>> parsing commandline options ? Do you use getopt() ? Or do you find
>> that real world programs have a simple enough set of options that
>> it's easier to write bespoke code?
>
> ​I've only written one program where i had to deal with command-line
> options, and when that happened i just used getopt(). That being
> said, were i to write any more programs like that i don't think i'd
> use it, in part because i think that the paradigm of the option is
> wantonly applied to every program without consideration for whether
> it's most optimal because it's just what everyone is used to.

What is your alternative to "the paradigm of the option"?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On Thursday, 27 July 2023 at 10:47:22 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > On Wednesday, 26 July 2023 at 23:45:06 UTC+1, Lynn McGuire wrote:
> >> On 7/26/2023 5:28 PM, Lynn McGuire wrote:
> >> > On 7/26/2023 10:34 AM, Malcolm McLean wrote:
> >> >> Just realised that my options parser isn't publically available, which
> >> >> I have just remedied.
> >> >>
> >> >> What approaches do people use towards parsing commandline options ? Do
> >> >> you use getopt() ? Or do you find that real world programs have a
> >> >> simple enough set of options that it's easier to write bespoke code?
> >> >
> >> > And what do you do about Unicode on your command line ?
> >> >
> >> > Lynn
> >> BTW, we rolled our own command line parser that handles Unicode.
> >>
> > You'd need to tweak the options parser slightly because it has a
> > concept of single character flags (so the user types something like
> > "tar -xvf file.tar" he's not passing one option "xvf", but three
> > flags). So it would have to be UTF-8 aware to accomodate Unicode
> > flags. Long options should work tranparently. It's maybe a worthwhile
> > change.
> I've never seen an option name that uses non-ASCII characters. The vast
> majority of option names use just letters, mostly lowercase --
> sometimes digits, and hyphens or rarely underscores for long option
> names.
>
That's worth knowing.
> Handling full UTF-8 for *arguments* to options is useful. Requiring
> non-ASCII characters as option names is going to make commands difficult
> to type for a lot of users.
>
The options parser is UTF-8 naive. So a filename with high Unicode characters
would just pass through. Similarly if you provide a long option with UTF-8,
that would be parsed. However currently it also takes a list of flags. These
are teated as single characters, so if you pass UTF-8, values over 127 will
be incorrectly treated.
If you are passed UTF-16 on the comandline, you'd have to convert to UTF-8.

On Wed, 26 Jul 2023 17:28:30 -0500
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> On 7/26/2023 10:34 AM, Malcolm McLean wrote:
> > Just realised that my options parser isn't publically available, which I have just remedied.
> >
> > What approaches do people use towards parsing commandline options ? Do
> > you use getopt() ? Or do you find that real world programs have a simple
> > enough set of options that it's easier to write bespoke code?
>
> And what do you do about Unicode on your command line ?

Nothing. I don't have options whose name includes (non ASCII) unicode and for
arguments which are not of a specialised nature (like numbers) , handling them
as an array of octets works fine. For example , pathnames on a Unix system
are arrays of octets so you just take the command line argument and you pass
it to fopen() .

On 2023-07-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Blue-Maned_Hawk <bluemanedhawk@gmail.com> writes:
>> On 7/26/23 11:34, Malcolm McLean wrote:
>>> Just realised that my options parser isn't publically available,
>>> which I have just remedied. What approaches do people use towards
>>> parsing commandline options ? Do you use getopt() ? Or do you find
>>> that real world programs have a simple enough set of options that
>>> it's easier to write bespoke code?
>>
>> ​I've only written one program where i had to deal with command-line
>> options, and when that happened i just used getopt(). That being
>> said, were i to write any more programs like that i don't think i'd
>> use it, in part because i think that the paradigm of the option is
>> wantonly applied to every program without consideration for whether
>> it's most optimal because it's just what everyone is used to.
>
> What is your alternative to "the paradigm of the option"?

One is environment variables.

Imagine the dd utility, with its keyword parameters:

dd if=this of=that count=42

If dd were converted to look up in the environment instead of the comand
line, then (in POSIX shell syntax), it could be invoked like this:

if=this of=that count=42 dd

It gets cumbersome to run such a program with fork and exec, because
there isn't any API for doing an exec with an environment array that
augments the current environment, rather than replacing it. Only if the
program (and its children, if any) never need any environment variables
other than the ones in its API, execv can be used.

Also, if a program needs other environment variables, then the problem
is that the argument ones are mixed up with the others; you don't have
nice "get me all my keyword arguments" access without naming all of
them. It's impossible to diagnose typos. If an argument is misspelled,
it disappears into the environment; the program has no way of knowing it
was one of the argument-like variables specified for that call.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

środa, 26 lipca 2023 o 17:35:05 UTC+2 Malcolm McLean napisał(a):
> Just realised that my options parser isn't publically available, which I have just remedied.
>
> What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?

i may not understand about what this topic is but in org-asm for comandline i use something most trivial

void ConsumeCommandlineOption(char* option)
{ if( strcmp ( option, "-noconsole" )==0) show_console = 0; else
if( strcmp ( option, "-console" )==0) show_console = 1; else
if( strcmp ( option, "-nolog" )==0) show_verbose_console_info = 0; else
if( strcmp ( option, "-log" )==0) show_verbose_console_info = 1; else
printf("\n ++++ option %s not reckognized and ignored ", option);

}
char* input_file_name = "input.asm";
char* output_file_name = "asm-result.exe";

int ConsumeCommandlineOptions(int argc, char* argv[])
{ if(argc==1 ) { PrintNoArgumentsInfo(); return 'stop'; }
if(argc>=2) { input_file_name = argv[1]; }
if(argc>=3) { output_file_name = argv[2]; }
if(argc>=4) { for(int i=3; i<argc;i++) ConsumeCommandlineOption(argv[i]); }

return 'ok';
}

its hovever dirty written and maybe i will revrite it..puting elses on right side is todays tiem invention (never seen this and today get idea to put it on right first time ;c ) using strcomp im not sure its okay as afair its a bit raw function, also this %s im not sure if its safe

fir <profesor.fir@gmail.com> writes:
>=C5=9Broda, 26 lipca 2023 o=C2=A017:35:05 UTC+2 Malcolm McLean napisa=C5=82=
>(a):
>> Just realised that my options parser isn't publically available, which I =
>have just remedied.=20
>>=20
>> What approaches do people use towards parsing commandline options ? Do yo=
>u use getopt() ? Or do you find that real world programs have a simple enou=
>gh set of options that it's easier to write bespoke code?
>
>i may not understand about what this topic is but in org-asm for comandline=
> i use something most trivial=20

You may wish to familiarize yourself with this:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

poniedziałek, 31 lipca 2023 o 18:33:10 UTC+2 Scott Lurndal napisał(a):
> fir <profes...@gmail.com> writes:
> >=C5=9Broda, 26 lipca 2023 o=C2=A017:35:05 UTC+2 Malcolm McLean napisa=C5=82=
> >(a):
> >> Just realised that my options parser isn't publically available, which I =
> >have just remedied.=20
> >>=20
> >> What approaches do people use towards parsing commandline options ? Do yo=
> >u use getopt() ? Or do you find that real world programs have a simple enou> >gh set of options that it's easier to write bespoke code?
> >
> >i may not understand about what this topic is but in org-asm for comandline=
> > i use something most trivial=20
>
> You may wish to familiarize yourself with this:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

okay, though not now..right now the trivial syntax i use is okay to me

On Monday, 31 July 2023 at 16:29:06 UTC+1, fir wrote:
> środa, 26 lipca 2023 o 17:35:05 UTC+2 Malcolm McLean napisał(a):
> > Just realised that my options parser isn't publically available, which I have just remedied.
> >
> > What approaches do people use towards parsing commandline options ? Do you use getopt() ?
> Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?
> i may not understand about what this topic is but in org-asm for comandline i use something most trivial
>
>
> void ConsumeCommandlineOption(char* option)
> {
> if( strcmp ( option, "-noconsole" )==0) show_console = 0; else
> if( strcmp ( option, "-console" )==0) show_console = 1; else
> if( strcmp ( option, "-nolog" )==0) show_verbose_console_info = 0; else
> if( strcmp ( option, "-log" )==0) show_verbose_console_info = 1; else
> printf("\n ++++ option %s not reckognized and ignored ", option);
>
> }
> char* input_file_name = "input.asm";
> char* output_file_name = "asm-result.exe";
>
> int ConsumeCommandlineOptions(int argc, char* argv[])
> {
> if(argc==1 ) { PrintNoArgumentsInfo(); return 'stop'; }
> if(argc>=2) { input_file_name = argv[1]; }
> if(argc>=3) { output_file_name = argv[2]; }
> if(argc>=4) { for(int i=3; i<argc;i++) ConsumeCommandlineOption(argv[i]); }
>
> return 'ok';
> }
>
> its hovever dirty written and maybe i will revrite it..puting elses on right side is todays tiem invention
> (never seen this and today get idea to put it on right first time ;c ) using strcomp im not sure its okay as
> afair its a bit raw function, also this %s im not sure if its safe
>
That bespoke code is simple enough to be a viable approach.
Wiht the options parser it would look something like this.

int main(int argc, char **argv)
{ OPTIONS *opt = options(argc, argv, NULL);
int show_console = 0;
int show_verbose_console_info = 0;

if (opt_get(opt, "-noconsole", NULL))
show_console = 0;
if (opt_get(opt, "-console", NULL))
show_console = 1;
if (opt_get(opt, "-nolog", NULL))
show_verbose_console_info = 0;
if (opt_get(opt, "log", NULL))
show_verbose_console_info = 1;

if (opt_Nargs(opt) != 2)
/* don't have two arguments */
if (opt_error(opt, stderr))
/* user passed an unrecognised or malformed option */
input_file_name = opt_arg(opt, 0);
output_file_name = opt_arg(opt, 1);

killoptions(opt)):

...

The big disadvantage is that you have an external dependency on options.c.

poniedziałek, 31 lipca 2023 o 18:46:10 UTC+2 Malcolm McLean napisał(a):
> On Monday, 31 July 2023 at 16:29:06 UTC+1, fir wrote:
> > środa, 26 lipca 2023 o 17:35:05 UTC+2 Malcolm McLean napisał(a):
> > > Just realised that my options parser isn't publically available, which I have just remedied.
> > >
> > > What approaches do people use towards parsing commandline options ? Do you use getopt() ?
> > Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?
> > i may not understand about what this topic is but in org-asm for comandline i use something most trivial
> >
> >
> > void ConsumeCommandlineOption(char* option)
> > {
> > if( strcmp ( option, "-noconsole" )==0) show_console = 0; else
> > if( strcmp ( option, "-console" )==0) show_console = 1; else
> > if( strcmp ( option, "-nolog" )==0) show_verbose_console_info = 0; else
> > if( strcmp ( option, "-log" )==0) show_verbose_console_info = 1; else
> > printf("\n ++++ option %s not reckognized and ignored ", option);
> >
> > }
> > char* input_file_name = "input.asm";
> > char* output_file_name = "asm-result.exe";
> >
> > int ConsumeCommandlineOptions(int argc, char* argv[])
> > {
> > if(argc==1 ) { PrintNoArgumentsInfo(); return 'stop'; }
> > if(argc>=2) { input_file_name = argv[1]; }
> > if(argc>=3) { output_file_name = argv[2]; }
> > if(argc>=4) { for(int i=3; i<argc;i++) ConsumeCommandlineOption(argv[i]); }
> >
> > return 'ok';
> > }
> >
> > its hovever dirty written and maybe i will revrite it..puting elses on right side is todays tiem invention
> > (never seen this and today get idea to put it on right first time ;c ) using strcomp im not sure its okay as
> > afair its a bit raw function, also this %s im not sure if its safe
> >
> That bespoke code is simple enough to be a viable approach.
> Wiht the options parser it would look something like this.
>
> int main(int argc, char **argv)
> {
> OPTIONS *opt = options(argc, argv, NULL);
> int show_console = 0;
> int show_verbose_console_info = 0;
>
> if (opt_get(opt, "-noconsole", NULL))
> show_console = 0;
> if (opt_get(opt, "-console", NULL))
> show_console = 1;
> if (opt_get(opt, "-nolog", NULL))
> show_verbose_console_info = 0;
> if (opt_get(opt, "log", NULL))
> show_verbose_console_info = 1;
>
> if (opt_Nargs(opt) != 2)
> /* don't have two arguments */
> if (opt_error(opt, stderr))
> /* user passed an unrecognised or malformed option */
> input_file_name = opt_arg(opt, 0);
> output_file_name = opt_arg(opt, 1);
>
> killoptions(opt)):
>
> ...
>
> The big disadvantage is that you have an external dependency on options.c..

yes thats why teh simmple approch is imo better at least in simple cases i now need
(though its not elastical, i would only use -something options and possibly arguments without of it without "-"
-setwindow 400 600 -noconsole

for extreme simplicity not using underscores and spaces i guess maybe pass strings by

-setwindow 400 600 -noconsole -settitle "green fire app"

but i dont know if argc/argv handles that " " strings (but if no and divides by space it is also not hard to code it by taking args to rightside in argv[])

BTW thsi pice i posted has better naming conventions imo, something i clarified for some years
imo they are good
1) not use abbreviations (with very few exceptions like sin cos min max and things like that)
2) write long function names, camel style, use long then you dont need to write commentary (typicaly 3 to 5 words but even 7 words function names are okay)
3) variabel names write lowcase with underscores (medium sized if they are sorta global/module scope)
4) you may use short variable names liek 1 letter if they are local, but also may write longer too
5) structure names as types write like Ship but entity like ship
6) dont use macroprocessor at all

there are yet soem additional less used conventions for function names like you may use underscored SomeFunction_postfix() in soem cases (generally also function are based on verb (with very few exceptions, like conversion functions, maybe isSomething functions and this like), variables on nouns,

teh code you posted breaks thoat rules (4-5 times: OPTIONS , opt, opt_get, opt_Nargs) so imo it looks worse stylistically (by convention style)

poniedziałek, 31 lipca 2023 o 19:12:56 UTC+2 fir napisał(a):
> poniedziałek, 31 lipca 2023 o 18:46:10 UTC+2 Malcolm McLean napisał(a):
> > On Monday, 31 July 2023 at 16:29:06 UTC+1, fir wrote:
> > > środa, 26 lipca 2023 o 17:35:05 UTC+2 Malcolm McLean napisał(a):
> > > > Just realised that my options parser isn't publically available, which I have just remedied.
> > > >
> > > > What approaches do people use towards parsing commandline options ? Do you use getopt() ?
> > > Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?
> > > i may not understand about what this topic is but in org-asm for comandline i use something most trivial
> > >
> > >
> > > void ConsumeCommandlineOption(char* option)
> > > {
> > > if( strcmp ( option, "-noconsole" )==0) show_console = 0; else
> > > if( strcmp ( option, "-console" )==0) show_console = 1; else
> > > if( strcmp ( option, "-nolog" )==0) show_verbose_console_info = 0; else
> > > if( strcmp ( option, "-log" )==0) show_verbose_console_info = 1; else
> > > printf("\n ++++ option %s not reckognized and ignored ", option);
> > >
> > > }
> > > char* input_file_name = "input.asm";
> > > char* output_file_name = "asm-result.exe";
> > >
> > > int ConsumeCommandlineOptions(int argc, char* argv[])
> > > {
> > > if(argc==1 ) { PrintNoArgumentsInfo(); return 'stop'; }
> > > if(argc>=2) { input_file_name = argv[1]; }
> > > if(argc>=3) { output_file_name = argv[2]; }
> > > if(argc>=4) { for(int i=3; i<argc;i++) ConsumeCommandlineOption(argv[i]); }
> > >
> > > return 'ok';
> > > }
> > >
> > > its hovever dirty written and maybe i will revrite it..puting elses on right side is todays tiem invention
> > > (never seen this and today get idea to put it on right first time ;c ) using strcomp im not sure its okay as
> > > afair its a bit raw function, also this %s im not sure if its safe
> > >
> > That bespoke code is simple enough to be a viable approach.
> > Wiht the options parser it would look something like this.
> >
> > int main(int argc, char **argv)
> > {
> > OPTIONS *opt = options(argc, argv, NULL);
> > int show_console = 0;
> > int show_verbose_console_info = 0;
> >
> > if (opt_get(opt, "-noconsole", NULL))
> > show_console = 0;
> > if (opt_get(opt, "-console", NULL))
> > show_console = 1;
> > if (opt_get(opt, "-nolog", NULL))
> > show_verbose_console_info = 0;
> > if (opt_get(opt, "log", NULL))
> > show_verbose_console_info = 1;
> >
> > if (opt_Nargs(opt) != 2)
> > /* don't have two arguments */
> > if (opt_error(opt, stderr))
> > /* user passed an unrecognised or malformed option */
> > input_file_name = opt_arg(opt, 0);
> > output_file_name = opt_arg(opt, 1);
> >
> > killoptions(opt)):
> >
> > ...
> >
> > The big disadvantage is that you have an external dependency on options..c.
> yes thats why teh simmple approch is imo better at least in simple cases i now need
> (though its not elastical, i would only use -something options and possibly arguments without of it without "-"
> -setwindow 400 600 -noconsole
>
> for extreme simplicity not using underscores and spaces i guess maybe pass strings by
>
> -setwindow 400 600 -noconsole -settitle "green fire app"
>
> but i dont know if argc/argv handles that " " strings (but if no and divides by space it is also not hard to code it by taking args to rightside in argv[])
>
> BTW thsi pice i posted has better naming conventions imo, something i clarified for some years
> imo they are good
> 1) not use abbreviations (with very few exceptions like sin cos min max and things like that)
> 2) write long function names, camel style, use long then you dont need to write commentary (typicaly 3 to 5 words but even 7 words function names are okay)

i meant PascalStyle.. the style you posted form me is like more gothic or yet maybe 19th century style (imo), what i write is imo more modern (pneumatic?)

this is probably all that abbreviations are 'cut' to/for the eye (as abrevviation cut words)
and this is not good.. imo using pascal for variables in turn is not good (so the options
for variables are mainly 3: classicc, this_one, camelStyle )yet is maybe 4th all big)..
i chosed underscored... if so then function names would to be nice to get different than
variables and Pascal imo looks really good (for pascal functions im more sure than underscored variables i guess (there is and option for pascal+camel instead of pascal+underscores i guess..
but not tested it

overally this convention i use is enough good imo but real mistake make all programmer who use abbreviations... in recent times i hovver began to consider if not use maybe not necassarely abbreviations but soem shorts (1 word lowercase eventually cut) for some arrays..becouse there are some arrays who tend to be writen in code thousands times, and maybe the things that do appear thousand times (like int, float) could and mabe even should be shorts

> 3) variabel names write lowcase with underscores (medium sized if they are sorta global/module scope)
> 4) you may use short variable names liek 1 letter if they are local, but also may write longer too
> 5) structure names as types write like Ship but entity like ship
> 6) dont use macroprocessor at all
>
> there are yet soem additional less used conventions for function names like you may use underscored SomeFunction_postfix() in soem cases (generally also function are based on verb (with very few exceptions, like conversion functions, maybe isSomething functions and this like), variables on nouns,
>
> teh code you posted breaks thoat rules (4-5 times: OPTIONS , opt, opt_get, opt_Nargs) so imo it looks worse stylistically (by convention style)

poniedziałek, 31 lipca 2023 o 18:46:10 UTC+2 Malcolm McLean napisał(a):
> On Monday, 31 July 2023 at 16:29:06 UTC+1, fir wrote:
> > środa, 26 lipca 2023 o 17:35:05 UTC+2 Malcolm McLean napisał(a):
> > > Just realised that my options parser isn't publically available, which I have just remedied.
> > >
> > > What approaches do people use towards parsing commandline options ? Do you use getopt() ?
> > Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?
> > i may not understand about what this topic is but in org-asm for comandline i use something most trivial
> >
> >
> > void ConsumeCommandlineOption(char* option)
> > {
> > if( strcmp ( option, "-noconsole" )==0) show_console = 0; else
> > if( strcmp ( option, "-console" )==0) show_console = 1; else
> > if( strcmp ( option, "-nolog" )==0) show_verbose_console_info = 0; else
> > if( strcmp ( option, "-log" )==0) show_verbose_console_info = 1; else
> > printf("\n ++++ option %s not reckognized and ignored ", option);
> >
> > }
> > char* input_file_name = "input.asm";
> > char* output_file_name = "asm-result.exe";
> >
> > int ConsumeCommandlineOptions(int argc, char* argv[])
> > {
> > if(argc==1 ) { PrintNoArgumentsInfo(); return 'stop'; }
> > if(argc>=2) { input_file_name = argv[1]; }
> > if(argc>=3) { output_file_name = argv[2]; }
> > if(argc>=4) { for(int i=3; i<argc;i++) ConsumeCommandlineOption(argv[i]); }
> >
> > return 'ok';
> > }
> >
> > its hovever dirty written and maybe i will revrite it..puting elses on right side is todays tiem invention
> > (never seen this and today get idea to put it on right first time ;c ) using strcomp im not sure its okay as
> > afair its a bit raw function, also this %s im not sure if its safe
> >
> That bespoke code is simple enough to be a viable approach.
> Wiht the options parser it would look something like this.
>
> int main(int argc, char **argv)
> {
> OPTIONS *opt = options(argc, argv, NULL);
> int show_console = 0;
> int show_verbose_console_info = 0;
>
> if (opt_get(opt, "-noconsole", NULL))
> show_console = 0;
> if (opt_get(opt, "-console", NULL))
> show_console = 1;
> if (opt_get(opt, "-nolog", NULL))
> show_verbose_console_info = 0;
> if (opt_get(opt, "log", NULL))
> show_verbose_console_info = 1;
>
> if (opt_Nargs(opt) != 2)
> /* don't have two arguments */
> if (opt_error(opt, stderr))
> /* user passed an unrecognised or malformed option */
> input_file_name = opt_arg(opt, 0);
> output_file_name = opt_arg(opt, 1);
>
> killoptions(opt)):
>
> ...
>
> The big disadvantage is that you have an external dependency on options.c..

depend what dependencies i guess - imo include "some.c" or -l"some.dll" ale sorta standable dependencies - but it also depends if thiose things you delegate to this side codes are of such kind you need update them or no update and mostly forget (if need to update the another branch od code-jumping may and probably will be weary) (this way the 'dead' code is much better than live branches that need to be jumped)

besides i dont know what killoptions(opt)) exactly do but such paradigm of new/free open/close
is bad and not should be used... malloc free for example should be used same way as goto
or recursion today it means nearly never except some so rare cases most people probably dont ever seen it - also this pattern.. there shopuld not be done what i call "temporal" states in programming..in programming you shoudl operate on ram state this is some "spacial" state not temporal ones..temporal are most evil

poniedziałek, 31 lipca 2023 o 20:21:36 UTC+2 fir napisał(a):
> poniedziałek, 31 lipca 2023 o 19:12:56 UTC+2 fir napisał(a):
> > poniedziałek, 31 lipca 2023 o 18:46:10 UTC+2 Malcolm McLean napisał(a):
> > > On Monday, 31 July 2023 at 16:29:06 UTC+1, fir wrote:
> > > > środa, 26 lipca 2023 o 17:35:05 UTC+2 Malcolm McLean napisał(a):
> > > > > Just realised that my options parser isn't publically available, which I have just remedied.
> > > > >
> > > > > What approaches do people use towards parsing commandline options ? Do you use getopt() ?
> > > > Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?
> > > > i may not understand about what this topic is but in org-asm for comandline i use something most trivial
> > > >
> > > >
> > > > void ConsumeCommandlineOption(char* option)
> > > > {
> > > > if( strcmp ( option, "-noconsole" )==0) show_console = 0; else
> > > > if( strcmp ( option, "-console" )==0) show_console = 1; else
> > > > if( strcmp ( option, "-nolog" )==0) show_verbose_console_info = 0; else
> > > > if( strcmp ( option, "-log" )==0) show_verbose_console_info = 1; else
> > > > printf("\n ++++ option %s not reckognized and ignored ", option);
> > > >
> > > > }
> > > > char* input_file_name = "input.asm";
> > > > char* output_file_name = "asm-result.exe";
> > > >
> > > > int ConsumeCommandlineOptions(int argc, char* argv[])
> > > > {
> > > > if(argc==1 ) { PrintNoArgumentsInfo(); return 'stop'; }
> > > > if(argc>=2) { input_file_name = argv[1]; }
> > > > if(argc>=3) { output_file_name = argv[2]; }
> > > > if(argc>=4) { for(int i=3; i<argc;i++) ConsumeCommandlineOption(argv[i]); }
> > > >
> > > > return 'ok';
> > > > }
> > > >
> > > > its hovever dirty written and maybe i will revrite it..puting elses on right side is todays tiem invention
> > > > (never seen this and today get idea to put it on right first time ;c ) using strcomp im not sure its okay as
> > > > afair its a bit raw function, also this %s im not sure if its safe
> > > >
> > > That bespoke code is simple enough to be a viable approach.
> > > Wiht the options parser it would look something like this.
> > >
> > > int main(int argc, char **argv)
> > > {
> > > OPTIONS *opt = options(argc, argv, NULL);
> > > int show_console = 0;
> > > int show_verbose_console_info = 0;
> > >
> > > if (opt_get(opt, "-noconsole", NULL))
> > > show_console = 0;
> > > if (opt_get(opt, "-console", NULL))
> > > show_console = 1;
> > > if (opt_get(opt, "-nolog", NULL))
> > > show_verbose_console_info = 0;
> > > if (opt_get(opt, "log", NULL))
> > > show_verbose_console_info = 1;
> > >
> > > if (opt_Nargs(opt) != 2)
> > > /* don't have two arguments */
> > > if (opt_error(opt, stderr))
> > > /* user passed an unrecognised or malformed option */
> > > input_file_name = opt_arg(opt, 0);
> > > output_file_name = opt_arg(opt, 1);
> > >
> > > killoptions(opt)):
> > >
> > > ...
> > >
> > > The big disadvantage is that you have an external dependency on options.c.
> > yes thats why teh simmple approch is imo better at least in simple cases i now need
> > (though its not elastical, i would only use -something options and possibly arguments without of it without "-"
> > -setwindow 400 600 -noconsole
> >
> > for extreme simplicity not using underscores and spaces i guess maybe pass strings by
> >
> > -setwindow 400 600 -noconsole -settitle "green fire app"
> >
> > but i dont know if argc/argv handles that " " strings (but if no and divides by space it is also not hard to code it by taking args to rightside in argv[])
> >
> > BTW thsi pice i posted has better naming conventions imo, something i clarified for some years
> > imo they are good
> > 1) not use abbreviations (with very few exceptions like sin cos min max and things like that)
> > 2) write long function names, camel style, use long then you dont need to write commentary (typicaly 3 to 5 words but even 7 words function names are okay)
> i meant PascalStyle.. the style you posted form me is like more gothic or yet maybe 19th century style (imo), what i write is imo more modern (pneumatic?)
>
> this is probably all that abbreviations are 'cut' to/for the eye (as abrevviation cut words)
> and this is not good.. imo using pascal for variables in turn is not good (so the options
> for variables are mainly 3: classicc, this_one, camelStyle )yet is maybe 4th all big)..
> i chosed underscored... if so then function names would to be nice to get different than
> variables and Pascal imo looks really good (for pascal functions im more sure than underscored variables i guess (there is and option for pascal+camel instead of pascal+underscores i guess..
> but not tested it
>
> overally this convention i use is enough good imo but real mistake make all programmer who use abbreviations... in recent times i hovver began to consider if not use maybe not necassarely abbreviations but soem shorts (1 word lowercase eventually cut) for some arrays..becouse there are some arrays who tend to be writen in code thousands times, and maybe the things that do appear thousand times (like int, float) could and mabe even should be shorts
> > 3) variabel names write lowcase with underscores (medium sized if they are sorta global/module scope)
> > 4) you may use short variable names liek 1 letter if they are local, but also may write longer too
> > 5) structure names as types write like Ship but entity like ship
> > 6) dont use macroprocessor at all
> >
> > there are yet soem additional less used conventions for function names like you may use underscored SomeFunction_postfix() in soem cases (generally also function are based on verb (with very few exceptions, like conversion functions, maybe isSomething functions and this like), variables on nouns,
> >
> > teh code you posted breaks thoat rules (4-5 times: OPTIONS , opt, opt_get, opt_Nargs) so imo it looks worse stylistically (by convention style)

as to style i probbaly should write back to furia compiler, but it needs partially deeper focus
when writing (though standable) so i dont know if i write now

some example that a;ready compiles https://fastupload.io/pakja4Guq471ngn/file

input is in input.c output is in furia-output.exe

it generally tends to be extremally simplified extended/modernized c 'variant' or how to call it

rhe funny pieces

void SetupLight
SetPointLight 0 1 -1100.0 0.0 0.0 7000.0 50000.0 0.30 1.9 1.3 1.3 0.01 0.01 0.01 0.18 1.1 1.1 1.1 0.01 0.01 0.01
SetPointLight 1 3 1100.0 500.0 500.0 7000.0 50000.0 0.30 1.3 1.9 1.3 0.01 0.01 0.01 0.18 1.1 1.1 1.1 0.01 0.01 0.01
SetPointLight 2 3 0.0 -1500.0 -500.0 7000.0 50000.0 0.30 1.3 1.3 1.9 0.01 0.01 0.01 0.18 1.1 1.1 1.1 0.01 0.01 0.01 ;

this is most simplified function definition - seems qyite okay (and it compiles so its proven to work)

void ProcessMouseMove mouse_x mouse_y { }
void ProcessKeyDown key { }
void OnResize { RunFrame }

alseo 3 function definitions

void RunFrame int advance
{
Initialise, ClearFrameData 0x666666
DrawLine3d 100.0 100.0 0.0 100.0 -100.0 0.0 0xffffff
DrawLine3d 100.0 -100.0 0.0 -100.0 -100.0 0.0 0xffffff
DrawLine3d -100.0 -100.0 0.0 -100.0 100.0 0.0 0xffffff
DrawLine3d -100.0 100.0 0.0 100.0 100.0 0.0 0xffffff
DrawDot3d 0.0 0.0 100.0 20.0 0x557788
DrawDot3d 0.0 0.0 150.0 30.0 0x557722
DrawDot3d 0.0 0.0 -100.0 10.0 0xaa7788
DrawCloud1, DrawCloud2, DrawCloud21,
DrawCloud3
DrawSomeText2F 0xa99999 0x666666 10 20 "hello, this is example program compiled by fir's furia compiler \x00"
}

same

ints array

new type - resizable array of ints
may be iaccesed by array[i] using array.size,
size just may be changed by array.size=29; array.size=100; etc
has alo method add: array.add(10)

i generate code in assembly for that, i got no head in that so i a bit forgot bout the code for eemiting resizes are sorta like

void EmitResize(chunk name, int size) //for seting new size
{ FlushOutAsm("\n push %d", size );
FlushOutAsmChunkPE("\n push (", name, ") ");
FlushOutAsm("\n call (\"msvcrt.dll\"->realloc)");
FlushOutAsmChunkPE("\n mov (", name, ") eax ");
FlushOutAsm("\n pop edx");
FlushOutAsm("\n pop edx");
FlushOutAsmChunkPE("\n mov (", name, ") eax ");
FlushOutAsm("\n mov eax %d", size);
FlushOutAsmChunkPE("\n mov (", name, "_size) eax ");
}