Priority range

[Ambrevar]

Priority must be between 3-8, but the help message does not say why. Digging in the source code I see that 0-2 and 9 are used for special purposes.

I think this design choice is confusing to the user and might yield even more confusing choice. Why not separating the concept of priority and status? Alternatively, you could keep the algorithm as it is but the user input would be an arbitrary number that you interpolate between 3 and 8. This way the user interface would be obvious and would not need further documentation.

[loh-tar]

When I understand right you suggest the user give prio 0 (for very high priority), I add 3 to this value and have my intern prio 3, which will then displayed by -l.

I'm not sure if this is not more confusing, but we can do it.

To solve this we need to save this user-prio and show it instead of current prio, just that the user feels good. How about only to enhance this help info?

• The job priority is not static and affect only the start time. Highest priority is 0

• The job priority is not static and affect only the start time. Highest priority is 0, priorities 0-2 are intern used, old jobs have prio 9

[Ambrevar]

You are right, it's not much clearer. What about separating the notion of priority and status then?

• Priorities can be any number.
• Jobs have a "status" property with possible values among stopped, paused, old, etc.

[loh-tar]

As you know current priority is intern necessary to do the whole job, it must be sort able. So separating means to keep an extra user-prio as wrote above.

[loh-tar]

How about to modify the -p command in a way that the user can only in/decrease the priority but not set explicit? Like so:

-p <id> [+]n|-n 
-p <id> +...|-...     # Or like this?

or perhaps a reverse order to change more than one job at once

-p [+]n|-[n] <id>...

whereas + may increase and - decrease priority, in sense of the word

[Ambrevar]

As you know current priority is intern necessary to do the whole job, it must be sort able. So separating means to keep an extra user-prio as wrote above.

Should not be a big issue, no? What about having different queues, one for stopped jobs, one for old jobs, etc.?

Let's think in terms of user interface: when the users want to add jobs, they will expect them to have all the same priority by default so that cpd is in charge of the scheduling. Sometimes, the users will want to copy urgent files, in which case they want to start a copy with higher priority. Conversely, sometimes they might have some big unimportant copy to perform and they'd like to reduce the priority.

I think it's important that the user can set high/low priority directly when starting a job.

Examples assuming status is separated from priorities:

$ cpd foo bar # priority 0

$ cpd -p -1 big-unimportant there # lesser priority

$ cpd -p 1 important-file here # higher priority

$ cpd -p 2 urgent-file here # even more important, takes priority over previous file.

Making 0 the default priority is easier to remember and probably more intuitive. Thus users can remember "the lower the number, the lower the priority, the higher the number, the higher the priority". Easy, no?

[loh-tar]

Aside from your new issue, to give the priority right with the new job, it looks to me identical with my suggestion giving an increase/decrease priority ;-)

I will change it this way, fine. But the displayed prio I will keep as it is for now.

[Ambrevar]

OK.

I still think it's better to separate the priority from the status and to have the priority display be 0 by default.

[Ambrevar]

Just a thought: say the user does:

$ cpd -p 0 foo1 bar1
$ cpd -p 1 foo2 bar2

and then wants to add a job that has higher priority than foo1 bet lower than foo2...

Thus I suggest to make priorities floating point numbers.

[loh-tar]

In this particular example there is no need for this, you can simple give the same prio as foo2. The jobs are sorted by prio and time.

Some lines are stripped

$ cpd /tmp/ foo1
$ cpd /tmp/ foo2
$ cpd -p 2 4 (to simulate not yet existing -p with the new job)
Change priority of job 2 to 4
$ cpd -l
ID PRIO STATUS   SIZE  DRIVE            TARGET                FILES
  2   4  pending     0  tmpfs            /tmp                  foo2
  1   5  pending     0  tmpfs            /tmp                  foo1
$ cpd /tmp/ foo3
$ cpd -p 3 4
Change priority of job 3 to 4
$ cpd -l
ID PRIO STATUS   SIZE  DRIVE            TARGET                FILES
  2   4  pending     0  tmpfs            /tmp                  foo2
  3   4  pending     0  tmpfs            /tmp                  foo3
  1   5  pending     0  tmpfs            /tmp                  foo1

Nevertheless I don't like to refuse this idea. Would it be ok when give -p 0.5 (in your example) the PRIO is re calculated like this:

$ cpd -l
ID PRIO STATUS   SIZE  DRIVE            TARGET                FILES
  2   3  pending     0  tmpfs            /tmp                  foo2
  3   4  pending     0  tmpfs            /tmp                  foo3
  1   5  pending     0  tmpfs            /tmp                  foo1

I still struggle to introduce a tracked user-prio. But I intend to use PRIO 8 for error jobs, this way they are on top when all is done and not somewhere dispersed.

Then there are 3-7 left for pending jobs, five, as now the default, with 2 above and 2 below.

And how about if -p N is as now the absolute PRIO and -p + or -p - to give it as relative value? So giving ++ or -- for more/less relative prio. Has the advantage not to confuse with different numbers on the command line and the -l output.

[Ambrevar]

I think this is all too shortsighted and complicated.

Having only 5 slots (3-7) for priorities is an arbitrary, unneeded limitation.

Let me give you another example:

cpd -p1 foo10 bar10
cpd -p1 foo11 bar11
...
cpd -p1 foo1n bar1n
cpd -p1 foo1n bar1n

cpd -p2 foo20 bar20
cpd -p2 foo21 bar21
...
cpd -p2 foo2n bar2n
cpd -p2 foo2n bar2n

Now how to I add a job that gets executed after the foo2 jobs but before the foo1 jobs? Of could I could write a loop to shift all the foo2* jobs to priority 3. Not really pretty though.

And what if I have exhausted all 5 priority slots? Then I can't insert a job in the middle of anything.

I might be missing something cause I do not really understand why you do not want to separate priorities from the status.

[loh-tar]

Now how to I add a job that gets executed after the foo2 jobs but before the foo1 jobs?

After think a little, it is the same answer: Simple use -p2

And what if I have exhausted all 5 priority slots? Then I can't insert a job in the middle of anything.

I don't know. As you see above the answers are often surprising. Resources are not endless, at some point you have to be careful how much you consume. There is no need to try to force each job to run with some extra high priority.

But ok, that's how the human tick. More-More-More. And because the job adding time influence the execution order it may be better to use as default PRIO 7. Then the user can only give more prio to come on before of something job.

I might be missing something cause I do not really understand why you do not want to separate priorities from the status.

I can't this clear explain, it is more like a gut instinct. But one point is clear. The status is a priority information of its own. Therefore must be a separate user-prio somehow mixed with the status. Perhaps it is quit easy and my worries are pointless. I tend to give all this prio stuff a low prio on my todo list.

The worries on both sides seemed to be a little overacted.

BTW: Handling of float numbers are a messy in bash

[Ambrevar]

After think a little, it is the same answer: Simple use -p2

Not the point. How do you change one of the existing jobs to run between foo1 jobs and foo2 jobs.

But ok, that's how the human tick. More-More-More.

It's not about more. It's about simplicity and flexibility.

BTW: Handling of float numbers are a messy in bash

Yup, but that you should expect from any program written in bash. In our case it's just one or two calls to bc, so I think we can go with that. If not, maybe we should consider another language.

[loh-tar]

Not the point.

I think it was exact on the point

How do you change one of the existing jobs to run between foo1 jobs and foo2 jobs.

Now you ask a complete different question

It's not about more. It's about simplicity and flexibility.

Cool down. I don't intended to be disrespectful. Sorry if it sound so.

After once more thinking about this prio issue, I believe we have to get rid of it at all.

The user is not interested in priorities but in execution order. So adding a job need not a prio option but a reference where it has to be sort in, like so:

$ cpc foo1 bar1
$ cpc foo2 bar2

$ cpd -l
job 1 foo1 bar1
job 2 foo2 bar2

$ cpc -top 1 foo3 bar3
$ cpc -top 2 foo4 bar4

$ cpd -l
job 3 foo3 bar3
job 1 foo1 bar1
job 4 foo4 bar4
job 2 foo2 bar2

$ cpd -mov 2 top 4 
$ cpd -l
job 3 foo3 bar3
job 1 foo1 bar1
job 2 foo2 bar2
job 4 foo4 bar4

[Ambrevar]

Cool down. I don't intended to be disrespectful. Sorry if it sound so.

You did not, I was not heating up :) Just wanted to clarify: it's not about features, but about design.

Agreed with the idea of replace priorities by order, what we want is a job queue in the end. Not sure about the commandline syntax though, I'll think about it.

[loh-tar]

Just a last question to this issue:

You may have noted that the default PRIO is changed down to 6 with only 7 left as lowest PRIO in my draft of the new user interface. After once more thinking I decided that there is no need for a lower user-prio by -p. Newer jobs are always below older jobs.

The only reason why I keep 7 below the default of 6 left is an example like this:

    $ cpc new job1
    $ cpc new job2
    $ cpc new job3
    $ cpd list
    job1
    job2
    job3

Now, how can we easy move job1 below all other jobs?

    $ cpd prio 7 job1

Without one free level below the default we have to move all other jobs higher. Yes, I know, you are eager to get the other stuff with the mov jobX below jobY syntax, but that must wait, sorry.

Now you can made suggestions how the prio command has to work, as it is with absolute numbers, my favorite because no more to do, or with a delta value, or both. Furthermore how the handling of wrong input has to be handled. Strict, or lazy, my favorite. e.g. giving a too high/low absolute value adjust it to the limits.

After that I like to close this issue. For the new stuff open a new ticket someone later, if you still need it after a decent period of time using cpd version 1.0

[loh-tar]

OK, this will closed soon but please give feedback about the new behavior.

I have code in a way to ignore most wrong user input. I think it's OK this way but perhaps you see it different.

Furthermore I choose the order 'prio jobs..' if you think 'jobs.. prio' is a must have let me know. Then I will go on and modify the other commands in the same manner.

[Ambrevar]

But I thought we dropped the idea of priorities in favour of queue re-ordering, didn't we?

[loh-tar]

For the new stuff open a new ticket someone later, if you still need it after a decent period of time using cpd version 1.0