Some notes on changes from Denizen to Denizen2.

[Anthony]

Queue management/manipulation is one of Denizens strong points. Let's not impede that unnecessarily. Again, we can easily use flags to track queues, but that is indeed another step in the process.

[mcmonkey]

Queue management/manipulation is one of Denizens strong points. Let's not impede that unnecessarily. Again, we can easily use flags to track queues, but that is indeed another step in the process.

None of you are clarifying how complicated Queue ID's help this at all.

[Anthony]

Queue management/manipulation is one of Denizens strong points. Let's not impede that unnecessarily. Again, we can easily use flags to track queues, but that is indeed another step in the process.

None of you are clarifying how complicated Queue ID's help this at all.

I'm not suggesting that the complicated and convoluted method of random text strings be maintained... the incremental numbering system is perfectly sufficient imo with the one caveat of having the originating script ID be the queue ID prefix.

[mcmonkey]

Queue management/manipulation is one of Denizens strong points. Let's not impede that unnecessarily. Again, we can easily use flags to track queues, but that is indeed another step in the process.

None of you are clarifying how complicated Queue ID's help this at all.

I'm not suggesting that the complicated and convoluted method of random text strings be maintained... the incremental numbering system is perfectly sufficient imo with the one caveat of having the originating script ID be the queue ID prefix.

Let me put it in BIG TEXT for you.
WHY

[Anthony]

Let me put it in BIG TEXT for you.
WHY

Because it's such a good idea that some genius dev decided that's how queues should be identified already... by name...

[mcmonkey]

Let me put it in BIG TEXT for you.
WHY

Because it's such a good idea that some genius dev decided that's how queues should be identified already... by name...

Not only does that linked code go directly against your own point, you failed to make a fully qualified point in the first place! Good job!

[AbiDada]

not to butt in here, but I think this answers your question mcmonkey:

[11:00] <BlackCoyote> lets say you have a while loop on the player, with irregular waiting periods in it, if the player logs out, the commands running behind that might error since the player is no longer online, we have 2 choices for this, put a check in front of every single command, or clear the queue when the player goes
[11:01] <BlackCoyote> clearing the queue is the more convenient solution to this in my experience, now we can track the queue in 2 ways
[11:01] <BlackCoyote> by keeping a list ourself, in flags or something, or by putting a prefix on the queue
[11:01] <|Anthony|> i name my queues intentionally for this exact reason
[11:01] <|Anthony|> to avoid having to manage queues in a flag data set
[11:01] <BlackCoyote> keeping the list yourself is tedious, lots of work, and a lot of things to account for just in order to make sure the flag always only shows active queues
[11:02] <|Anthony|> the necessary data should be built right into the name of the queue

[mcmonkey]

not to butt in here, but I think this answers your question mcmonkey

Please present your own response or allow the relevant people to present their own answers.

As was mentioned later in that channel, that response isn't particularly sufficient and was yelled in anger by annoyed users rather than well thought out.

My question stands:

WHY does having queue's prefixed with a script title help anything at all ever?

[Anthony]

An example scenario is this: things such as webget and sql take an amount of time and should be done in the background. Running these functions with a known name allows you to easily and reliably check for a current process if triggered again. A real world example right here relating to webget.

[mcmonkey]

An example scenario is this: things such as webget and sql take an amount of time and should be done in the background. Running these functions with a known name allows you to easily and reliably check for a current process if triggered again. A real world example right here relating to webget.

So that doesn't answer the whole "script title prefix" thing, but it does pose an alternate point which needs a response.

If I read you correctly, you want a way to determine rapidly if a queue for a certain process is already running.

There are a variety of better ways to do this than custom ID's.

Some examples include:

- (Best) Store a flag somewhere indicating the queue. If the flag is present and the queue held by the flag is valid and running, the process is running.

- (Alternate) Take the tag that returns a list of all queues, filter it for being run by the relevant script or containing other identifying data, and if you get back a list with one or more entries, you have both the queue and a reference to the queue.

A thing to consider when you're wanting queue ID's is this:

Can you give custom ID's to players? NPCs? /Anything/? No, you can't. You either leave a marker on them and search for the marker, or add them to an external named reference. What's wrong with doing the same for queue's?

[Anthony]

Any opportunity to exclude managing an external lookup table is a performance increase both on the read and the write. It is assumptive logic... a consistent naming convention that removes extra steps in logic is smart coding.

[mcmonkey]

Any opportunity to exclude managing an external lookup table is a performance increase both on the read and the write. It is assumptive logic... a consistent naming convention that removes extra steps in logic is smart coding.

By requiring script names (as opposed to numeric IDs), you're creating an /internal/ lookup table... which, in D2, is no more efficient than an external one for most cases.

In fact, writing your own specialized code would be /more/ efficient than a general for-all-queues name-based lookup table!

It is assumptive logic... specialized code that reduces general complexity is smart coding!

[BlackCoyote]

Any opportunity to exclude managing an external lookup table is a performance increase both on the read and the write. It is assumptive logic... a consistent naming convention that removes extra steps in logic is smart coding.

By requiring script names (as opposed to numeric IDs), you're creating an /internal/ lookup table... which, in D2, is no more efficient than an external one for most cases.

In fact, writing your own specialized code would be /more/ efficient than a general for-all-queues name-based lookup table!

It is assumptive logic... specialized code that reduces general complexity is smart coding!

I happily believe that your current idea is going to be most efficient for d2. But you have to take into account the main reason why denizen is used. use of ease.denizen is meant to be really easy to use and to do otherwise complex things with.

If you're going to strip the features that make it easy to use, to make it faster, you're making it more and more viable for users to instead directly program their own thing as a plugin rather than use denizen as a middle way.

Lets meet in the middle, and introduce a 'prefix' option for queue IDs, that are stored externally from queues, but still internally in d2 for the convenience of the scripter. this would only be optional and should only be affecting efficiency rates when actually utilized.

[mcmonkey]

Lets meet in the middle, and introduce a 'prefix' option for queue IDs, that are stored externally from queues, but still internally in d2 for the convenience of the scripter. this would only be optional and should only be affecting efficiency rates when actually utilized.

Code: Select all

- define queue_prefix "MySpecialQueue" <[run_queue]>

:D ?

[BlackCoyote]

Lets meet in the middle, and introduce a 'prefix' option for queue IDs, that are stored externally from queues, but still internally in d2 for the convenience of the scripter. this would only be optional and should only be affecting efficiency rates when actually utilized.

Code: Select all

- define queue_prefix "MySpecialQueue" <[run_queue]>

:D ?

me and anthony both use <queue.definitions> to return a complete list of arguments passed into a function. If we're going to have to filter out specific cases out of that list, every time, simply because we need an identifier, it again goes at cost of the user's ease of use and efficiency.

[mcmonkey]

me and anthony both use <queue.definitions> to return a complete list of arguments passed into a function.

wh... why?

I can almost understand that in D1 (ALMOST) but in D2... where you can use a MapTag if you need a set of keys and values, ...?

[BlackCoyote]

me and anthony both use <queue.definitions> to return a complete list of arguments passed into a function.

wh... why?

I can almost understand that in D1 (ALMOST) but in D2... where you can use a MapTag if you need a set of keys and values, ...?

The maptag sounds like a neat thing, however it wouldn't work too great for API's wanting to make the user input as simple as possible. being able to pass 1|2|3 is a lot easier for the user than a=1|b=2|c=3. for some of us maptags might be extremely simple, but for beginners who need denizen because things otherwise get too complex, it is only pushing the bar up higher for them.

[BlackCoyote]

aditionally, a maptag would mean processing raw dlist inputs, for example <context.args> into a maptag or some sort, which would mean additional work and complexity for scripters.

[mcmonkey]

The maptag sounds like a neat thing, however it wouldn't work too great for API's wanting to make the user input as simple as possible. being able to pass 1|2|3 is a lot easier for the user than a=1|b=2|c=3. for some of us maptags might be extremely simple, but for beginners who need denizen because things otherwise get too complex, it is only pushing the bar up higher for them.

If the input is just 1|2|3, then make the input .... 1|2|3, as a ListTag.

I suggested a map tag cause I assumed you wanted definition names. If that's not needed, then just a simple list will fully suffice.

[BlackCoyote]

so you want me to make sure the end user passes the undefined list, as a single definition, and then have me, inside the script recieving that list, turn it back into individual definitions?
once again that becomes more work and makes denizen less user friendly than when we could just pass context[<dlist>] and have each argument ready as its own definition.