LÖVE

bartbes wrote:If you use cron.update, does it update all tags too?

Yes. cron's non-tagged functions work as before - update(dt) updates all existing entries (no matter their tags), cron.cancel(id) cancels an individual entry, and cron.after & cron.every create non-tagged entries.

There is no way to "update only the non-tagged entries", though. I experimented using cron.tagged() - with no params - but I encountered one case where the logic wasn't quite clear/didn't work for some reason. In any case, that's not a problem I wanted to solve.

The main problems I wanted to deal with where:

• Using cron inside a "game paused" menu - now I can do cron.tagged('pause-menu').update(dt) and the rest of the tags will freeze naturally.
• A complex instance (like an enemy) could have more than one cron entry simultaneously. When the enemy is killed, cancelling all those ids is tiresome. Now cron.tag(self) can create/cancel all the relevant entries for that enemy quite easily (tags can be anything - strings are just one possibility)

That makes sense, but I think your documentation may be lacking, then, when I (addmittedly) glanced over them, I couldn't find anything related to the scope of the 'global' functions with respect to tags.

Ok, I'll try to improve that (I accept pull requests, too )

A little off topic but...
I notice that your libraries are weak tables:
e.g. tweens = setmetatable({}, {__mode = "k"})
What does that buy you?
Does that mean that the compiler will depreciate any function not called or is this strickly to prevent memory leakage?
Still learning and appreciate any input.
Best

Ref wrote: What does that buy you?
Does that mean that the compiler will depreciate any function not called or is this strickly to prevent memory leakage?

Let me start by saying that in the case of tween, I think that might be a mistake (the tweens table should be strong, not weak).

The only use I have for weak tables is to prevent memory leakage.

A lot of my libs "archive instances of stuff in private collections". When these instances are stored in an array-like table, that is no problem at all. The problem is that I end up using other stuff as keys - often the instances themselves. My policy is: if I'm using something given by the user as a key, then I must use a weak table. cron.lua has weak tables on the scopes (internal objects that you create when you do cron.tagged(<blah>) because the <blah> part can be tables provided by the user). But notice how it doesn't use a weak table on the entries collection any more. (That's one of the fixes hawahoo sent me)

When your "main collection of instances" (entries in cron, or tweens in tween) is weak, but the references are self-generated, you risk losing instances when the garbage collection runs. This is unlikely in the case of tween, since it uses the tweens as keys and values, but I guess it could happen.

Initially, tween was supposed to accept keys given by the user as keys. That's why it used a weak table for them. Then I realized that I'd rather generate the ids myself, but then I forgot to undo the change. I must fix this. Thanks for helping me identifying a possible issue!

Thanks for the information - very interesting!

cron 2.0 is out!

This new version is backwards-incompatible with the previous version, but it should (hopefully) be easier to use.

On version 1.0, cron hold an internal list of "clocks", and every time you called cron.update, all the clocks would update. This was not very convenient because one often wants to update some clocks but not others.

On version 1.5, I tried to fix that issue by adding tags - groups of clocks that could be activated and deactivated independently. This kindof worked, but made the code huge (more than duplicated it). You could now update groups of clocks separatedly, but updating then in order, or doing stuff between updates, was not possible

On version 2.0 I have decided to simplify. The library creates clocks, but it does not automatically hold references to any clocks; instead, it returns them to the user, so each clock can be updated separatedly. The trouble with this approach is that if all your clocks worked the same way before, they could be updated with a single call to cron.update, and now you need to store them in a table and update them with a loop. But only the simplest games using time will be on that situation, so I consider this an improvement.

Version 2.0 does not add any new features or fixes new bugs, so if you feel comfortable with previous versions of cron, you can use the previous ones. But if you are starting a new project, I recommend using 2.0, since it's the most flexible one and also the one I will be supporting from now on.

Regards!

I've edited the OP to reflect the changes in 2.0.

Do you think you're going to update it for 0.9.1?

cron.lua does not depend on any part of LÖVE. It's compatible with any LÖVE version without needing any changes, as far as I know.

EDIT: I just tried the demo on the OP using 0.9.1 and it worked just fine.

Hm. I just get a "callback must be a function" error.
EDIT: Wait, no, looked at the example. Now nothing happens.