[QUOTE=preda;507900]Should it stop afterwards? (ignoring worktodo.txt)[/QUOTE]


Yes. This is only meant for quick testing and validating.

[QUOTE=SELROC;507898]I have been thinking and rethinking on this: a command line argument to specify the exponent to compute. That is may be "-c <number>" should start gpuowl and compute <number>. It could be useful.[/QUOTE]Maybe call it -exp. Or something that distinguishes it as PRP3 as opposed to P-1 (-pm1)? -c might be confused with -cpu.

I'd like to see either at command line or worktodo entry (both choices would be nice but maybe not a good use of Mihai's time budget) an option to do -iters (number). If I had to pick one, I'd choose command line. The combination of SELROC's suggestion plus -iters would make benchmarking the various fft lengths for a given gpu model much easier. As is, I find myself babysitting it. Mlucas and prime95 have the -iters feature.

An option on worktodo entries -fft +(number) or -(number)would be useful. As is, a worktodo file can't efficiently mix exponents of different fft list offset.

Also if there's an issue with one worktodo entry instead of quitting, continue to the next.
Openowl could modify the trouble assignment to be a comment, then rescan the file for input.

[QUOTE=kriesel;507909]Maybe call it -exp. Or something that distinguishes it as PRP3 as opposed to P-1 (-pm1)? -c might be confused with -cpu.

I'd like to see either at command line or worktodo entry (both choices would be nice but maybe not a good use of Mihai's time budget) an option to do -iters (number). If I had to pick one, I'd choose command line. The combination of SELROC's suggestion plus -iters would make benchmarking the various fft lengths for a given gpu model much easier. As is, I find myself babysitting it. Mlucas and prime95 have the -iters feature.

An option on worktodo entries -fft +(number) or -(number)would be useful. As is, a worktodo file can't efficiently mix exponents of different fft list offset.

Also if there's an issue with one worktodo entry instead of quitting, continue to the next.
Openowl could modify the trouble assignment to be a comment, then rescan the file for input.[/QUOTE]




Mfakto has the argument -tf <exp> <bitmin> <bitmax>
it ignores the worktodo file, so for consistency with mfakto:


openowl -prp <exp> ...

[QUOTE=SELROC;507917]Mfakto has the argument -tf <exp> <bitmin> <bitmax>
it ignores the worktodo file, so for consistency with mfakto:

openowl -prp <exp> ...[/QUOTE]

Makes sense.
openowl -pm1 <exp> -B1 <b1bound> -B2 <b2bound>

[QUOTE=kriesel;507956]Makes sense.
openowl -pm1 <exp> -B1 <b1bound> -B2 <b2bound>[/QUOTE]


the -B1 and -B2 are not strictly necessary:


openowl -pm1 <exp> <b1bound> <b2bound>

[QUOTE=SELROC;508000]the -B1 and -B2 are not strictly necessary:

openowl -pm1 <exp> <b1bound> <b2bound>[/QUOTE]
True. I think it would be easier to read though with them. It also maintains a symmetry in parsing; one field identifier, one value, rather than one with 3 parameters and order-sensitive.

[QUOTE=kriesel;508001]True. I think it would be easier to read though with them. It also maintains a symmetry in parsing; one field identifier, one value, rather than one with 3 parameters and order-sensitive.[/QUOTE]


Let preda decide on this, but I am just curious what you have against order-sensitive arguments :-)

How it typically works is that an op has either nothing or one string attached to it. This makes arg parsing a doddle with something like getopt, which easily allows defining a short and long version of an op like -h and --help. Personally I'd convert the arg parsing to getopt and do "openowl --pm1 <exp>,<b1bound>,<b2bound>" assuming the bounds are only used with pm1.

[QUOTE=M344587487;508008]How it typically works is that an op has either nothing or one string attached to it. This makes arg parsing a doddle with something like getopt, which easily allows defining a short and long version of an op like -h and --help. Personally I'd convert the arg parsing to getopt and do "openowl --pm1 <exp>,<b1bound>,<b2bound>" assuming the bounds are only used with pm1.[/QUOTE]

Is getopt available on windows? (for people building on windows)

An internet search indicates it's available on MingW/cygwin and that workarounds for MSVC appear to simply copy getopt.h from MingW ( [url]https://www.codefull.org/2015/04/cannot-find-getopt-h-header-file-when-compiling-under-windows/[/url] ). What a pain MSVC is.

[QUOTE=preda;508009]Is getopt available on windows? (for people building on windows)[/QUOTE]

getopt has been used as part of lasieve which compiles in pretty much all environments(these days). There was a bit of issue with POSIXLY_CORRECT not being set sometimes when compiling on windows which is worth watching out for. This was discussed in [url]https://www.mersenneforum.org/showthread.php?t=18043[/url]