An approach is needed to identify unique MuseScore objects from within the PluginAPI.

What is "valueOf"? I gather you (DLL) looked for it and found naught.... I see -- it's a JS primitive that is delegated to objects to handle however they want. Not clear how that fits into this issue.

According to the JS documentation, it calls a function on the prototype. How would it help if the wrapper supplied that function? What could it return that has any more permanence than the address of the "real object"?

Actually my idea with defining a valueOf() function turns out to be incorrect. The idea was based on the fact that when comparing two variables of different types in JavaScript using == operator the engine tries to convert them to some common type: to Number using valueOf() or to String using toString(). If the same worked for objects then we could define such a conversion in a way that would allow a comparison be performed in the way we need. However when comparing two variables of the same type == is defined by the language standard to be the same as strict comparison (===) which, in case of objects, returns true only if the same object is compared with itself. This makes the entire idea not working.

So far I see the following ways to resolve the issue:

1. Define ScoreElement.is() function
   We could perform a comparison via a specially defined function:

var score1 = curScore;
var score2 = curScore;
if (score1.is(score2))
    console.log("this is the same score");

This is essentially the same as an elementId approach except that the actual value used for a comparison is never exposed to a plugin. This resolves the main downside of the elementId approach as we can usually safely assume that the object that is referenced in a plugin does actually exist and is not deleted.

2. Implement extension objects instead of wrappers
   QML allows defining extension objects for arbitrary types in order to define some QML-accessible properties for it without modifying its source code. That would potentially allow both manipulating the original objects from libmscore and leave the API implementation separate from libmscore. However extension objects can define only additional properties but not additional functions. This would force us to move Q_INVOKABLE functions defined in plugins API directly to the types in libmscore which makes this solution not much better then the following one:

3. Get rid of wrappers and move plugins-related properties and functions back to libmscore
   The main issue here is that plugins API becomes tightly coupled with libmscore structure and this adds a lot of limitations both on libmscore development and on plugins API. Functionality exposed to plugins has some specific requirements: it should always track the object's ownership (plugins vs. C++ code), changes made to a score from plugins should always be undoable, it should always check input values to make it impossible (or at least harder) to crash MuseScore, it sometimes uses different measurement units (like spatium for offset of elements in plugins vs. pixels for the same purpose in libmscore), and generally ease of use has somewhat more priority over a performance there. On the other side, plugins API should stay compatible within the whole 3.X release cycle which would also limit the development of libmscore.
   While it would probably be good to structure libmscore in a way that it starts having a stable API and becomes easier to use, this would currently require a lot of changes. Simply moving Q_INVOKABLE functions from plugins API to the respective types in libmscore would currently cause name conflicts which will be difficult to resolve. For example, the recently added Chord.add() function does not really correspond to Chord::add() function in libmscore: Chord::add() is designed to be a lower-level function which does not take undoability of operations into account and does not try to ensure the correct state of the score after it is executed. Renaming this function in plugins API would complicate the plugins API, and renaming that function in libmscore would require changes throughout the entire MuseScore code.

4. Return the same wrapper for the same object: mapping approach
   The other possible solution is to ensure that the same wrapper is returned for the same object. As BSG mentioned, one possibility is to store some mapping of elements to their wrappers in the plugin engine. QObject::destroyed signal from wrappers can be used to track when they get destroyed in order to remove them from that mapping.

5. Return the same wrapper for the same object: member variable approach
   The other way to ensure equality of wrappers could be to cache the pointer to the used wrapper in the ScoreElement object from libmscore itself. This would make searching for a wrapper faster as no search in a mapping would be required, but that would make libmscore use a bit more memory for each element which can be somewhat significant for the entire score. That cache pointer could though be made possible to disable at compile time if no plugins framework is used. It should be noted that Qt itself also uses a similar approach (QObject implementation stores a variable that contains data used by the declarative QML framework).

6. (didn't check but may be working) Return a non-pointer type to QML plugins
   Currently we typically create a wrapper object and return a pointer to it to QML framework. If we return some non-pointer type instead which has operator== correctly overloaded (and registered to Qt meta-object system) then we could probably make a comparison working properly. That would require though to change the underlying object's lifetime management system: deleting such a wrapper wouldn't mean that the underlying object should be deleted if it doesn't belong to a score. Also it should be checked first whether that approach allows to expose properties to QML framework correctly.

Conclusion

I simply listed the options I see and I am not currently ready to say which approach would be better here. Still, if an immediate solution is needed, the first approach (with is() function) could probably be implemented: while it is also not perfect, it doesn't seem to have large downsides and can easily be adapted without losing a compatibility if we still opt for some solution to ensure uniqueness of wrappers in the future. Still if there are some strong objections against the very model of creating wrapper objects each time on demand then we can certainly reconsider it, for example using the approaches described here.

Sorry, didn't intend to change a status

Wow! Thanks for this thesis-level (or at least article in a technical journal) effort, considering everything that has been said. i will be studying it all morning.

Unlike the case in Clinton saga, it doesn't matter what the meaning of "is" is. Simply comparing two objects for equality of base object is marginally useful. For scores, it's useful. For notes, it's not. If (as I could do with ElementId) I want, in QML, to maintain my own data associated with, say, a Note, I cannot (with this scheme). There is no way to build a (JS) mapping (or "dictionary" in ECMA5) by which I can find it; I would have to keep track of every single note ever returned and do an "is" test against every one to find the object (wrapper or my own) that I am using as a canonical one. This has quadratic inefficiency problems. (More to follow as I think these over).

Nor do I see why (1) solves the problem of deletion. If the JS code retains a reference to an object which is deleted later in the course of plugin execution, it occurs, so the plugin framework still needs a way to revoke objects already handed to JS, whether or not the base object address is used in the role of a UID.

See my comment of 6:57. #1 is very flawed, as there is no way to find objects, once gotten, except by linear searching through every single object of that type that you ever received. There must be some kind of identifier that allows dictionaries to be made, if properties cannot be set. What kind of things would (1) enable other than to say "I saw this score before!"? And, AFAICT,it doesn't solve the problem of deletion.

The issue I want to solve is being able to, in Javascript, make my own notations or observations about some object, say, a Note, and I don't care whether it's by means of properties, or other objects I construct as long as I can find them from Notes, which with (1) I cannot without keeping track of every Note I have ever seen in an array and searching linearly to test for "==" on each of them. This doesn''t fly.

I suppose I could create a function that computes some crazy hash of the pitch, tick, duration, voice number, and anything else I can get, and search a hash bucket chain of previously-returned notes of that hash class, requiring a separate algorithm and hash table for each object type I needed. But this is a bit like "teaching the Pope how to pray"... (i.e., subsuming a function that should be provided), a fragile, hard-to-explain, harder-to-justify (to plugin coders) kludge at best. And this only works for objects whose union of POD artifacts is reasonably unique; it would not work, for instance, for NoteEvents.

Using my nonexistent football (American) skills, kick it down the road some. No pressing need. The proposed solutions are all very disruptive. foo.is() might be an acceptable compromise to faciitate the hash scheme I just proposed, if it can be done without too much disruption. At least for Notes, I don't even think we need that (because the POD set is so uniquizing). But at least it's upward-compatible. Comparing leaf-POD including tick, voice, pitch, tpc, etc could serve as == today.

"Plain old data" (i.e., nonstructured, primitive values). The term even appears in some clang (Mac C/++ compiler) error messages. It is so that two notes (almost) cannot occupy the same pitch, voice, tick etc at the same time (they can -- see image - but it's very, very rare). There is no real substitute for pointer comparison. Day 1 of Lisp is that EQUAL is not the same as EQ (and this is true in any language with pointers). If you modify one of two EQUAL things that are not EQ (i.e., two identical notes at the same pitch and tick), the other does not change. A mashed "comparison value" does not substitute for identity, but could be a cue in a hash-based algorithm. It is not an adequate substitute.

How about foo.is() for 3.3 as proposed, with the understanding that it can be made useful, if not perfect (deletion issue there today) with the hash scheme I described (can even handle twin notes when both parts available), and will become meaningless when two non-EQ wrappers for the same underlying object will not, in the future, even be possible? It has the advantage of being upward-compatible.

Wow! I'll buy that! But you can't possibly test it in time for 3.3 -- every known plugin has to be verified operative.

Needless to say, you're gonna clobber the variable when the JS engine tells you that the avatar has been GC'ed, and when plugin execution terminates....and this approach #5, not #4.

I'm a little afraid to test this because, by your description, it will without doubt crash the second time I invoke the plugin. You can tally up a vector of every ScoreElement into which you've stuffed a pointer and loop through it at the end. the GC case is harder, whereupon use std::unordered_set instead. I know there is a callback for "JS GC terminating object".

Bravo, anyway!

Probably won't be able to get to it this evening, but if you send me a url I can clone from, I'll try. Surely, you are in control when the plugin is finished, and you can rain down the Objektengötterdämmerung without being told to by JS....(and doing it twice should be a no-op).

> This hit for storage space for the back pointer in Ms::ScoreElement to the wrapper object may be more than compensated by not having so many wrapper objects being created.

For those users who do not use plugins this will just add up a memory usage though. It will likely be not very large though, at least for a normal usage on desktop systems.

Still I have a question regarding storing additional element's data in a plugin. Having unique wrappers for objects would not enable using mappings in any way. Am I correct then that your intention is to assign some property to a wrapper object to be used later? I am not sure that it will work that way (although it is likely to work) since it will be some internal QML engine object that will receive this property assignment, not a wrapper itself, and we do not control lifetime of those objects directly. If it turns out to be working we may need also to change ownership of wrapper objects to CppOwnership to make those data persist across plugin invocations or even when receiving a wrapper object for some element two times within the same plugin invocation. But then memory leaks and properties name conflicts between plugins may become possible. We will probably need to deal with these issues somehow.

No, I only hope to store javascript properties in the javascript visibility of the wrapper to be used during the present run of the present plugin, not persisting in any way beyond the execution of the plugin. The latter would be extravagant and outside of the charter of plugins. No mapping of any kind is needed if that much works, and if any mapping were needed, the JS object pointers are perfectly fine map keys. Am I answering your question?

There ought be some way of plugins communicating across invocations, or even between plugins, or even between MS invocations, but the "properties" mechanism used for saving UI settings of plugins already is to a limited extent, but that is a wholly separable issue that can be addressed by a wholly separate design.

I will zipclone, build, and play with this in a few hours. This is amazing work. I was gearing up do it myself, but you've mostly done it already. This is absolutely the right way.

I've never used a dock-type plugin, but what happens if more than one of them are up at once? Can that be? Are there multiple javascript worlds active at once!?!?! That can't be! I must not understand "dock-type plugins". Anybody? One I can try?

Yes, one part of my concerns is exactly about the case when multiple plugins are running simultaneously. Dock-type plugins are one example of that case: they allow to implement a dockable widget which can be used as a part of MuseScore interface. The plugins framework currently lacks a system of events which would notify plugins of some score or application state changes, that could potentially make such plugins much more useful. Also such widgets do not currently persist across MuseScore sessions. Still yes, it would be natural to allow several such plugins to run at a time, and no restrictions are made for that currently. For the unique wrappers problem this implies that several plugins may try to assign properties with the same name for the same object which would potentially create issues in their functionality.

My other concern which I tried to express in my previous comment is about preserving the properties within the same invocation of a single plugin. Consider the following code:

var sel = curScore.selection;
sel.elements[0].someCustomProperty = "someCustomValue";
gc(); // garbage collector may potentially trigger at any time, we'll force it just for demonstration purposes.
console.log(sel.elements[0].someCustomProperty);

It looks like the expected result here would be that someCustomProperty property of the selected element will be preserved after gc() call. But if we allow QML engine manage wrapper objects' lifetime then the corresponding wrapper with any corresponding properties will be deleted, and a new wrapper will be created when we try to access that element again. This means that a plugin developer may safely assume that the information will be preserved only if some reference to every element with such information is explicitly kept in a plugin. This does not seem to be a good limitation from a plugin development perspective since it will be easy to miss that, and, furthermore, this problem will be difficult to discover since not keeping such links will lead to losing information only sometimes, not fully reproducibly.

Concerning dock plugins, a Chord Identifier plugin is an example of it, when launching this plugin a widget appears at bottom-left corner which allows (after resizing it) to define some settings for finding chords. There is an improved version of this plugin but it seems to have switched from dock to dialog type.

If the wrappers are shared between plugins running concurrently, then storing properties in them is ruled out (although careful selection of names could partially address that). Serendipitously, you are now forced to have a javascript map/dictionary (stored in a plugin-local property var) to maintain properties, i.e., mapping javascript objects to "property bags" (i.e., dictionaries). And you know what? That would reference-count the object (used as a key), which would preserve it across garbage collections. So maybe the rule should be, "you can't assign user properties to these wrappers" (maybe could we enforce that somehow), and if you want to do that, you have to make a reference-preserving map/dictionary mapping objects to dictionaries of properties, and just make (or we supply) 2 javascript shim functions to get and set them. How's that?

A dock-type plugin, which I am to understand cedes control to the user like a non-modal Windows dialog, has bigger problems than being undercut by other plugins. Such a plugin may never, ever, store any state or determination about any score, including a pointer to any object, because the user might totally change or delete any or all notes or scores before the next time it is asked to act. If, during response to a click, it were to store properties in objects, it must remove them upon exit from the click -- if all plugins followed that protocol it would be "ok", but not only is that failure-prone, but the map-table way is safer if noncooperating agents are operating in parallel on the same score. Programming considerations for interaction between dock-type and non-dock-type plugins must be a chapter in "the book".

A dock-type plugin that stores a pointer to an object and expects it to be there in the next interaction has already "violated the law". The user can delete the object as well as can another plugin.

In any of the proposals (let alone today!), if you run your example 4 lines, you will print out two different addresses visible to the eye. But if a program neither stores properties in the object (which we will outlaw) nor retains a pointer to it, the program has no way to observe or notice that the objects values are not the same (EQ), nor can it possibly make a difference to the functioning of the program for that very reason.

Perhaps the Plugin Creator is viewed by the system as a "non-modal dialog/active/dock plugin" itself, and, hence, objects are not destroyed after each "Run"; this is probably wrong, but suggests that the only right time for Objektdämmerung is when the "active plugin count" goes to zero, now that "the plugin" is meaningless in light of dock plugins. But, then again, no dock plugin should be in possession of any object pointers when not actually handling a click.

The upshot of last night's discussion is that there is no such thing as "the plugin returns": all the active plugins (with docking plugins, there can be more than one) run in the same Javascript engine and space (without which the notion of exposing internal objects as their own avatars, as it was in the previous MS would be meaningless) It's pretty tricky for concurrent plugins to clobber each other inadvertently, because they store into plugin-scoped variables, not "truly global" ones. If they tried to clobber a global resource such as a class prototype, they sure would trouble each other. And if we don't prohibit storing into uniquized wrappers for MS objects, they can misinteract in that way, too. But the most interesting way they can damage each other is implicit in the model, and not a JS issue -- plugin A retains a pointer to a note, and either the user or plugin B deletes that note by explicit action. The user case is more revelatory of the problem than the Plugin B case. Nonmodal/docking plugins are basically tool palettes, which can customize their own UI state, but not dialogue with the user about an ongoing score-modifying action. They cannot, for instance, remember the last note they worked on and move on from there when a button is pushed; the user could delete that note before pushing the button. Garbage collection issues in the next message.

We have to draw a distinction between two operations, garbage collection, through which wrappers and other objects to which no references are held, in any plugin, are destroyed, and what I have been calling Objektdämmerung ("Twilight of the Objects"), in which all wrappers and other objects are destroyed. It could be (it probably is -- you can verify this), that when any plugin returns (no matter how many are active), it relinquishes all references it retains, MS wrappers or other, and not before then. If that is so (I hope it is -- we have to verify), then there should be no MS objects unrelinquished anywhere when "the last plugin returns", and GC should "devolve" to Objektdämmerung, and we are home free. See if this is the case. In one coherent JS space, it should never hurt of one plugin calls (gc) on the JS side; the definition of "care" is that no plugin can care about any object which it has neither modified nor retained a reference to.

Does this make sense?

The "scripting documentation" has to explain the axiom that if you save a reference to an internal object, and ask for the same object later, and see if they are the same (EQ), they WILL BE, even if this plugin or another plugin has provoked or invoked a garbage collection. Corollary to this is (1) today it is simply not so! The same object is NEVER returned! " and (2) if you're just breakpointing or console.log'in successive calls to see if the same object is returned, and you didn't save a reference to it, you didn't read the axiom carefully enough . It has to be explained that could we not differentiate between objects you literally cared about and others, garbage collection of objects would be impossible. Corollary to this is that storing user properties in these objects is not permitted.

What are "excerpts"? Does the above strategy provably destroy all wrappers that were created by any plugin, i.e., is the hypothesis of plugin return letting go of all of them hold true?

I will do so this afternoon!

Here's a piece of dismal news from testing. Object references cannot be used as keys in Javascript dictionaries, but can in Maps (or Python or C++) which, unfortunately, are only in ECMAscript 6, which will never appear on the Mac, including mine, because Qt 5.12 doesn't support OsX 10.10/11. That's rather terrible. So if plugins that have to run on the Mac want to keep objects around, they'd better do so in a list or set, and if they want to associate properties with them, there is no choice but linear lookup or store a user property with a "plugin-unique name" (e.g, "chord_plugin__propdict") in addition to saving in a set/list. I recommend restoration of ElementId (with a goofier name, like "IdHash") which, while not ensuring identity (=== will do that), facilitates building a hash table to substitute for what ECMAScript 5 cannot do. Yes, it is a kludge, but no more so than running Qt 5.9 on the Mac and 12 on Windows supporting 2 different JS languages.

Excerpt is the term used in MuseScore code for extracted individual parts of a score: https://musescore.org/en/handbook/3/parts

Concerning the main topic of this discussion, theoretically it should not be necessary to force garbage collection of unused objects after plugin has ended its execution: QML engine should probably run it itself, although it may happen less often. Also it should be noted that this model of storing pointers to wrappers in ScoreElement objects seems to be able to partially resolve a problem of references to deleted elements in plugins. In ScoreElement destructor we can delete the corresponding wrapper object too. Even though wrappers can be left with JavaScriptOwnership it should be safe to delete them: wrappers are QObjects and have means to notify QML engine of their destruction. Qt documentation seems to imply that trying to access such a deleted QObject from JavaScript code will result in script exception which would terminate a plugin but not crash the entire MuseScore program. Moreover, it may happen that such exceptions can be captured and handled in JavaScript code itself so with some extra accuracy plugins may even be able to deal with such issues gracefully.

Still I would say it resolves only a part of possible issues since there would be still no means to detect whether element actually belongs to a score or is already stored in undo stack, and failing to determine this correctly may result in placing something to undo stack twice which would result in a crash later. For example it seems that nothing stops a plugin from removing the same element from a score twice, and it is not clear currently how to prevent such situations both in plugins and in C++ code.

Simply "direct comparison" is not enough. I want to be able to mark objects (say, in a graph algorithm, or assigning musical analyses to them temporarily, etc). There are only 2 ways known to me to do this, store user properties in the object (which has problems with concurrent plugins, but that can be kludged with "sufficiently funny names":) , or storing them in a proxy object/dictionary findable from the wrapper object. This requires making a map of some kind. In ECMA6, there are such maps. In lower ECMA, I cannot use dictionaries in that way, although I can build a table in which I look up every object whose user properties I want to know. Since I cannot make a dictionary keyed by objects, I have to make a linear array of all such objects, which may be hundreds, and look them up linearly by === (which works now). In the absence of Map, I can only build a faster hash table if I have something wide-spreading but not necessarily unique, such as address (say as valueOf?). But in fact, two successive objects cannot occupy the same place in memory as false alias, by the way, unless the first was garbage-collected, which can only happen if no one had any references to it and, thus, "can't tell", i.e., can't make the mistake. So "valueOf" returning the address, would be plenty. If the object were deleted by C++ action, the earlier wrapper has to be marked "invalid to use", something today's strategy can't do. A badly-behaving dock plugin can sequester such pointers today. The documentation will be grim.

Excerpt is the internal name or extracted or linked parts

That's just terrific! That's very, very wonderful.

How about valueOf or something like it to facilitate hashing in ES 5?

In the words of the Beatles,, yeah, yeah, yeah! That's terrific. I'll make a better try at playing with it tomorrow now that it's all in place! I'll download it then in case anything changes.

I am testing this. Two observations so far. It seems elementId is still there, and both it and valueOf() work as hash keys. elementId is considerably more efficient, and in view of the ECMA problem, ought stay IMO.

Secondly, the plugin creator is not working properly. Using the name "tie-tests-hashing.qml", the "Reload" button is not reloading, and the "save" button complains "cannot determine file type". Interestingly, the tooltip over the lower pane shows the pathname truncated , i.e., "/Users/bsg/Documents/MuseScore3Development/Plugins/tie-tests-h". 62 characters. Is there a 64 character buffer in its path somewhere?

Yes, renaming to "a.qml" works properly, but not "tie-tests-hashing.qml", although the display is truncated further back ("/Users/bsg/Documents/MuseScore3Development/Plugi"). There is a bad bug here, or a couple.

I received this (in creator) when I executed QtQuit(): Warning: Signal QQmlEngine::quit() emitted, but no receivers connected to handle it.

I ran the following test; "walk one staff" prints out notes in several revealing forms, including as a raw object pointer:

hashes = {}
console.log("First pass, setting hash table")
walkOneStaff(0, computeHashes);
console.log("#hashes= " + obj_count);
console.log("Second pass, report hashes found")
walkOneStaff(0, report_notes);
console.log("Garbage collect, report again -- should all be there");
(gc)
walkOneStaff(0, report_notes);
console.log("Clear dictionary, report again")
hashes = {};
walkOneStaff(0, report_notes);
console.log("Now gc again, report again");
(gc);
walkOneStaff(0, report_notes);

And although all the tests up until "hashes = {}" report the same (EQ) objects every time, as hoped, after clearing the table and even a gc, the addresses printed out are one-for-one identical for eight notes, which, although "theoretically possible" is still suspicious.

Here are more interesting results. My test plugin had been storing properties in the wrappers, and I wondered if that is what was making it fail to collect the objects. So I removed the code that did that. Amazingly, each time I ran the plugin from the creator, the objects were still there, with the properties from preceding runs! I even closed the creator and brought it up again, and the same remained true. The objects persisted beyond the up-ness of any plugin, unless the creator itself is considered a plugin (as I wondered about yesterday). I had to close the score and reopen it to see new objects without the properties. This clearly indicates that there is no eagerness to clean them up. And even in that case, the same object pointers were returned after hash-table clear and gc.

>I don't think any of that is from my patches. I didn't wander anywhere near that code.

I'm sure it's not, but you still know that code better than I do ...I could still debug it...

I will d/l again. No, I don't have any dock plugins, nor do the plugins I did use (red note, articulation, just testing) retain pointers, especially since they are not dock plugins! Non-dock plugins should not be ABLE to retain references beyond their run, right, i.e., they have no way to do so. As I said, my test plugin is deliberately retaining and relinquishing references in a controlled fashion ... the collection of purportedly unreferenced objects is exactly what it tests.

Both are very short and to-the-purpose; real easy. Just downloaded, will build and test now. But my other plugins don't retain pointers, and I didn't use them on every note, and every note was retained.

Same. I did nothing at all after invoking the app other than bring up the Creator, load into it this plugin, and run it. The "quit not handled" persists, too. Is this the right branch? https://github.com/DLLarson/MuseScore/tree/plugin-object-comparison-fix ? Enclosed are the .mscz and the .qml.

The "quit" problem is solved, but the objects continue to report as having the same addresses even after a relinquishing of references and explicit (gc). Of course, this is not a "problem", except insofar as it reveals that the life-cycles of the objects are not behaving as we expect. See what you can learn...

There is a difference, though - if I run the plugin again, from the Creator, the objects do not have the same addresses as during the previous run, which is a hopeful sign. But around the relinquishment and GC, they do.

I thought I had posted my better version of the plugin that annotes address discord without retaining pointers, but I don't see it. Here it is again.

That is a true testament about who I am. Do you know why I wrote (gc)? A lifetime of Lisp!!!! When I think of GC, I think of Lisp (where such a call would be so stated!!) A both embarrassing and amusing error! The score getting GC'ed is probably correct, and has to be special-cased. But we are definitely nearing completion... Would cur_score survive gc in today's installed code?

This is very interesting. I don't see right now why that happens, will need to look at it closer.

There a certain number of variables, like "cur_score", which provide "roots" of plugins' access to MS data structure. It would seem to me that the wrappers for the objects they designate should be "C++ owned", i.e, not subject to garbage collection. It cannot be a large number of objects.

it sounds like the right answer is making the score wrapper C++-owned. What does that function look at? How does this behavior change in the release code?

Yes, but do the "failing" scripts fail in the installed code base?

Why doesn't the installed codebase lose objects with even greater alacrity, given that the whole point of the current project is to hold them closer?

I'm looking for a way to debug Qt at all on the Mac as you apparently can on Windows; Matt advised me to "insert print statement"...

Option -w should get you past that startcenter issue. Are you running musescore3.exe from the build or the install directory? The former would explain the workspace crash

This new approach is the other extreme of the current (3.2) policy, which latter is "create wrappers whenever an object reference is asked for, garbage collect them as needed, no promise of object identity preservation ever." This new approach is "object identity preserved forever, even between subsequent runs of the same or different plugins (as long as the score exists) and no garbage collection of wrappers, ever." We can't find the right "middle point" because we don't know why curScore, the value of a legitimate variable, is not preserved during a garbage collection when the C++ code is responsive to JS object collection (as it is not in this push). This answer is "conservative" insofar no objects or pointers will get lost. But it does raise the issue of VM consumption if a large score is traversed in QML, instantiating tens of thousands of wrappers that will never go away until the score does. It also says that (in this plan) marking wrappers from Javascript in anyway is a bad idea, for the marks will appear the next time the plugin is run (unless you consider that a feature and code to it, which is an iffy proposition). Maybe "the lifetime of a wrapper is the lifetime of the underlying object (the essence of this proposal)" is a reasonable definition.

That would indeed be ideal if it can be shown that there are no other "magic objects" (or they can all be found, washed, shaved, and conscripted), and that extant plugins can be proven to work well.

Great! Now we need a QA plan for the whole scheme ... presumably gc now calls the notification "slot" callback and disconnects the realobject in all those cases...

My plugins are not working at all against this push. The articulation plugin comes up without values in its window about 50% of the time, and if I try it in the PluginCreator, it doesn' seem to know what QtQuit() means. It did say this in the creator:
Running…
Plugin Details:
Menu Path: Plugins.Articulation
Version: 3.2
Description: This plugin adjusts the on/off times of a note.
Requires Score
Debug: hello adjust articulation: onRun
Debug: No region selection.
Debug: sel note count 0
Debug: 1 selections
Debug: element.type=19
Debug: on time 0 len 1000 off time 1000
Debug: No note at Apply time.
Debug: No note at Apply time.
Debug: No note at Apply time.

It's having trouble finding the selected note, and maybe keeping it. That's the installed 3.2 version of the plugin.

I don't remember if I did. How do I back out one with the git command? Happens on any score, but not 100% of the time, but without fail after 10 attempts on different notes. Plugin qml source is in the place pointed to by the plugins page; it is the 3.2 installed version. Just click on notes and see if the plugin comes up empty. If you run it in the creator, you will not be able to quit - that fails 100% of the time.

Here's the score and the plugin. You must assign a keystroke to it. Open this score, and just click on notes and issue the keystroke for each, type ESC. Sooner or later, the plugin window will come up without values in it. This absolutely does not ever happen in 3.3 beta. Try to run it in the creator and the "cancel" button or "ESC" do not work.

I see. Here they are.

Don't worry about selecting multiple notes for now. If you click on a place with no notes, it will issue that message. It should never say that if you really clicked on a note. There are no ornamented notes in that score, btw. It doesn't respect multiple-note selections -- you are supposed to use ranges (I'm not sure that that is undesirable). If you can click on notes anywhere for three minutes straight and see the plugin with real (not greyed-out) numbers in it every time, I either have a mac-specific problem or didn't make clean hard enough.... Also try quitting and restarting musescore and retrying it several times.

I had to be very devious. When run in "the Creator" (omnium pluginum Creator), it doesn't fail -- the Creator affects gc behavior. I remembered that Qt trace output, which includes plugin vocalizations, goes to stdout. So I ran ./mscore from the subdirectory of the app, and watched the terminal window. BINGO.
qml: Score
ScoreFont::draw: invalid sym 0
qml: hello adjust articulation: onRun
qml: No region selection.
qml: sel note count 0
qml: 1 selections
qml: element.type=19
qml: on time 0 len 1000 off time 1000
qml: hello adjust articulation: onRun
qml: No region selection.
qml: sel note count 0
file:///Users/bsg/Documents/MuseScore3Development/Plugins/articulate.qml:124: TypeError: Cannot read property 'elements' of null

123-125:
var selection = curScore.selection;
var elements = selection.elements;
if (elements.length == 1) { // We have a selection list to work with...

Curscore ran off to the dog pound.

FWIW
[bsg@bsg-mbp-2019 MuseScore (plugin-object-comparison-fix)]$ git show
commit 61a3e784447c41f785bf3ce3d0e35d77ada2a113 (HEAD -> plugin-object-comparison-fix, origin/plugin-object-comparison-fix)
Author: Dale Larson
Date: Wed Sep 11 10:27:21 2019 -0500

Plugin: WIP: Revert prior commit to only affect curScore object.

This restricts changes of wrapper ownership to CppOwnership for objects
returned by the `curScore` scripting property.

I just posted what git show said. It is fine to call the plugin when there is no selection. Works every time in 3.3 Beta. curScore.selection returns an empty array in that case (as I can prove by doing it and not seeing that script error). What's worse, there was a selection. Note also that it said it couldn't extract the "selection" property of null- the unambiguous implication is that curScore is null.

If I do five or six applications to random notes, the fifth or sixth one fails.

Well, if I could be another (Hans Leo) hassler .... I'm the one with the most vested interest in its outcome! I'll try that.

It goes without saying that 3.3Beta works flawlessly with all the plugins (just making sure you know).

Experiment one - failed in two applications:
qml: No region selection.
qml: sel note count 0
file:///Users/bsg/Documents/MuseScore3Development/Plugins/articulate.qml:124: TypeError: Cannot read property 'elements' of null
^C
[bsg@bsg-mbp-2019 MuseScore (plugin-object-comparison-fix)]$ git show
commit 9b231f5cee265096b5c72489888cf7d9b0bec953 (HEAD -> plugin-object-comparison-fix)
Author: Dale Larson
Date: Tue Sep 10 09:37:27 2019 -0500

Plugin: WIP: Change ScoreElement based wrapper ownership.

Change Ms::PluginAPI::ScoreElement based wrapper ownership

Experiment 2 :

qml: element.type=19
qml: on time 0 len 950 off time 950
qml: hello adjust articulation: onRun
file:///Users/bsg/Documents/MuseScore3Development/Plugins/articulate.qml:64: TypeError: Cannot call method 'createPlayEvents' of null
^C
[bsg@bsg-mbp-2019 MuseScore (plugin-object-comparison-fix)]$ git show
commit 0b3d4a281d581d59f6dd2fd6f7e7698f03bfb395 (HEAD -> plugin-object-comparison-fix)
Author: Dale Larson
Date: Wed Aug 28 12:30:59 2019 -0500

Fix #293837: Plugin: WIP: Add ability to compare MuseScore QML elements

This patch ensures that there is only one QML wrapper object for
each internal object that is exposed to scripting. This enables
simple sameness comparisons between javascript objects.

As expected, no failure here:
c^C
[bsg@bsg-mbp-2019 MuseScore (plugin-object-comparison-fix)]$ git show
commit 46da22f9e4d10d0f5e1f4f483d773ebcdf4635a3 (HEAD -> plugin-object-comparison-fix)
Author: Dale Larson
Date: Tue Aug 27 09:03:52 2019 -0500

Fix #293837: Plugin: WIP: Add ability to compare sameness of MuseScore QML elements.

A property named 'elementId' has been added to all score elements
so that QML scripting can compare two different QML elements to see
if they are accessing the same MuseScore object beneath the plugin

It seems you should be able to duplicate this easily, staying out of the plugin creator and watching output on stdout.

I did lie -- it's the style these days (but I did it unintentionally) -- it said no 'elements' property of 'selection', so the curScore object was there, but its selection property, which should be and is there even if there is no selection, was null (not "undefined", mind you). Is the pointer to "selection" a weak pointer of some kind (I thought you needed ES6 for that). You are using ES5/Qt5.9 as I am, aren't you? Shouldn't the array be created if it's not there when asked for? (note that there actually is a selection in the failing case).

You must use 5.9 as I am (and other Mac users are forced to).. Mac users will never get 5.12 as long as support for MacOS 10.10 and 10.11 is a business requirement. You haven't duplicated the failure yet, right? 3.3 will create a new wrapper any time an object is asked for. It can never fail.

This is in 3.3 Beta standard? It should be easy enough to create a plugin that does nothing more than try to access curScore.selection.elements and report curScore.selection being null, which should not happen, even if there is no selection. Again, it can't run in the Creator, because that suppresses failure. If there was a garbage collection, it is reasonable that the selection array should have been garbage collected, and the pointer set to null (C++). But it is not reasonable that when I asked for it, it did not recreate it.,

I created a minimal plugin (attached) that does, as I suggested, nothing (after "create note events", as articulate does) but check for curScore.selection being absent. Unfortunately, against the current branch, I can invoke it 25 times in a row (watching console log via previous kludge) and not see a failure, but if I try the art. plugin, I get a failure in three tries. I can't really explain that.

I tend to agree that this project is moribund, esp. in the face of the 5.9/5.12 problem, which, as I feared, as you note, has already started to cast a pall over the whole plugin world, and not just for Javascript versions. I tend to concur that, esp. given the lack of interest by others, "Retreat to ElementID" makes the most sense. Note that someone else (i.e., other than me) complained about the removal of object-EQness.

Thanks for your effort on this. Maybe we will learn something in the future, but it doesn't look worth it now (if there were QT bug, it might get QT attention if it weren't 5.9-specific).

"Sad".

Fixed in branch master, commit 52f744ec7a

fix #293837: plugins: add is() function to check if variables represent the same object

For the time being I pushed a change which implements the approach with is() function, this seems to be the safest and fastest way to resolve the issue for now. Later we can return to the approach with ensuring unique wrappers but for now that would be a large change given the time we have to test it before 3.3 release.

Anyway, @DLLarson, thanks a lot for your research on this, I hope to be able to have a look at the issues you listed once 3.3 version gets prepared.

Fixed in branch 3.3rc, commit ff8c615774

fix #293837: plugins: add is() function to check if variables represent the same object

Automatically closed -- issue fixed for 2 weeks with no activity.