Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Spider Monkey Panel (foo_spider_monkey_panel) (Read 347711 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.


Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #452
@TheQwertiest
I was building foo_spider_monkey_panel just fine and then I upgraded to VS2019 - 16.6, and the kmeans code throws errors wherever ranges::... is used. I think this is probably fixed by bumping up the range submodule dependency, but it looked like you were purposefully using an older version. Am I out of luck here?

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #453
@MordredKLB , haha, well I've updated my VS as well and it indeed fails to build, but not in `range-v3` part :P
What is the commit that your range submodule is on? (`cd submodules/range` & `git status` ).

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #454
@MordredKLB , haha, well I've updated my VS as well and it indeed fails to build, but not in `range-v3` part :P
What is the commit that your range submodule is on? (`cd submodules/range` & `git status` ).
Well, After rebasing last night to get your 16.6 changes, everything is good again, and DEBUG builds just fine. I still can't build release versions though.

I'm getting dozens of these 3 errors which shows me they're all related, but I can't figure out where the mismatch is coming from:
Code: [Select]
LNK2038	mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in abort_callback.obj
LNK2038 mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MT_StaticRelease' in abort_callback.obj
LNK2001 unresolved external symbol __CrtDbgReport
Also, when I try and use the debug build I made, foobar tells me I have missing dependencies.

This is why I should stick to JavaScript :D

Edit: I'm realizing now that I can probably use your "pack_component.bat --debug" script to build the debug component, which I guess is really all I need to be able to do.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #455
Seems like your solution has a mix of statically linked and dynamically linked projects. They all need to be the same.

edit: and debug/release mixed up too??

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #456
Seems like your solution has a mix of statically linked and dynamically linked projects. They all need to be the same.

edit: and debug/release mixed up too??
Yeah, it's weird. I haven't touched any of that stuff either. Fresh pull, run setup.py, open the .sln file and attempt to build release. All the components are set to RELEASE as well. Either way, I can now build a debug component and that's what matters.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #457
You have to "Rebuild" the project when you change configuration. This is caused by some *make based dependencies (scintilla, lexilla), which output binaries to the same path in Release and Debug configuration (and they do not detect automatically the change in configuration to trigger the rebuild).



Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #460
@snotlicker , it seems that these projects can only produce dynamic libraries, so it's not really suitable for SMP =(

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #461
I normally use dynamic but did a quick test with static and it compiles and works just fine??

Perhaps you need to update your linker settings to remove the .lib file previously generated by nmake??

edit: here's a screenshot of my own project - note the increased file size on the right!

https://i.imgur.com/5CX6MTc.png

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #462
I normally use dynamic but did a quick test with static and it compiles and works just fine??
`*.lib` file that is produced by `Scintilla.vcxproj` is an export library. So if you link against it, it will actually link you against corresponding `*.dll`. You can test this by removing said `*.dll` file (the program should crash or disable the component once it tries to load the component library)).

[edit]: https://i.imgur.com/JT8l35w.png
As you can see *.lib has the size of only 2KB vs 2MB of *.dll.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #463
You have to "Rebuild" the project when you change configuration. This is caused by some *make based dependencies (scintilla, lexilla), which output binaries to the same path in Release and Debug configuration (and they do not detect automatically the change in configuration to trigger the rebuild).
Ugh, should have thought to try that since it was clearly a release/debug mismatch. It's getting close to a decade since I worked professionally in VS/C-development so I've forgotten a few tricks.
Thanks for merging that PR!

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #464
@snotlicker , it seems that these projects can only produce dynamic libraries, so it's not really suitable for SMP =(

Since I was locked on version 4.3.3, I didn't understand this issue but I guess you were on latest commit when you tried. Since a new version was released yesterday, I encountered the same issue and reported it here...

https://groups.google.com/forum/#!topic/scintilla-interest/vnegGNO6nKw

 It has now been fixed in version 4.4.2.


Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #465
Code: [Select]
image_cache = function () {
    this._cachelist = {};
    this.hit = function (metadb) {
        var img = this._cachelist[metadb.Path];
        if (list.drag_stop && typeof img == "undefined") {
            if(!cover.load_timer) {
                cover.load_timer = window.SetTimeout(function() {
                    utils.GetAlbumArtAsync(window.ID, metadb, 0, true, false, false);
                    cover.load_timer && window.ClearTimeout(cover.load_timer);
                    cover.load_timer = false;
                }, 20);
            };
        };
        return img;
    };
    this.getit = function (metadb, track_type, image) {
        var img;
        var quotient = (panel.flat_mode) ? 2 : 12;
        if(cover.keepaspectratio) {
            if(!image) {
                var pw = (cover.w+cover.margin*quotient);
                var ph = (cover.h+cover.margin*quotient);
            } else {
                if(image.Height>=image.Width) {
                    var ratio = image.Width / image.Height;
                    var pw = (cover.w+cover.margin*quotient)*ratio;
                    var ph = (cover.h+cover.margin*quotient);
                } else {
                    var ratio = image.Height / image.Width;
                    var pw = (cover.w+cover.margin*quotient);
                    var ph = (cover.h+cover.margin*quotient)*ratio;
                };
            };
        } else {
            var pw = (cover.w+cover.margin*quotient);
            var ph = (cover.h+cover.margin*quotient);
        };
        // item.cover_type : 0 = nocover, 1 = external cover, 2 = embedded cover, 3 = stream
        if(track_type!=3) {
            if(metadb) {
                img = FormatCover(image, pw, ph);
                if(!img) {
                    img = nocover_img;
                    //item.cover_type = 0;
                } else {
                    //item.cover_type = 1;
                };
            };
        } else {
            img = streamcover_img;
            //item.cover_type = 3;
        };   
        this._cachelist[metadb.Path] = img;
        return img;
    };
};
Help convert

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #466
Version: 1.3.0
Link: https://github.com/TheQwertiest/foo_spider_monkey_panel/releases/tag/v1.3.0
Changelog:
Spoiler (click to show/hide)
Detailed description of API changes: https://theqwertiest.github.io/foo_spider_monkey_panel/docs/script_documentation/api_changes/#v130


Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #468
I'm seeing phantom tooltips that keep coming back after a script crashes and you reload it. I maxed out at 5 visible on top of each other at the same time. No real rhyme or reason I can tell to why they show up (or what values they have), but switching to foobar from another tab causes them to show again.

Seems like on a script crash Tooltip.Deactivate() might need to be called internally?

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #469
I discovered this evening that gdi.LoadImageAsync can return the same task ID at certain times which was a serious problem when I was attempting to load two large images somewhat simultaneously and then check then check the IDs in the callback. Was pretty simple to migrate over to LoadImageAsyncV2 (which is much cleaner as well!) but still kind of a confusing problem.

I'm also running into a memory leak when doing window.Reload(). I tried some pedantic stuff to reproduce but it seems garbage collection works fine, except in my theme.

My foobar starts at around 250MB, and adds 10-20MB (seems somewhat dependent on size of the active playlist) each time I do a window.Reload(). Eventually foobar is using 1.3TBs and I get error messages like this immediately after my theme loads and I have to restart foobar:
Code: [Select]
Error: Spider Monkey Panel v1.3.0 (Georgia v2.0.0 by Mordred)
Out of memory: 4057804/1073741824 bytes

Still trying to figure out if there's something I can do to minimize things, or not.

Edit: Seems I can mitigate things somewhat by setting playlist = null; and all of WillB's library objects to null before doing window.Reload(). Somehow it seems objects in the global namespace get orphaned references on a window.Reload... and I have a lot of stuff in the global namespace.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #470
SetFont doesn't work.
Haha, welp, that's what I get for being lazy and not testing things properly =)
Thanks for reporting.

I'm seeing phantom tooltips that keep coming back after a script crashes and you reload it.
Strange, that should not happen. I'll take a look if I can reproduce it.

I discovered this evening that gdi.LoadImageAsync can return the same task ID at certain times
Do you mean that that `LoadImageAsync()` returns the same ID when ran serially? E.g.
Code: [Select]
ids = []
for (path in paths)
{
  ids.push[gdi.LoadImageAsync(path)];
}
// ids not unique

Task ID is just an object's memory address. The only way they could have the same id (in theory) is when the memory is reused (which is possible only if the previous task was finished and handled in the callback).

I'm also running into a memory leak when doing window.Reload().
Still trying to figure out if there's something I can do to minimize things, or not.
Regretfully, it's nearly impossible to fix such leaks without at least somewhat minimal repro scenario.
Try downloading debug version of SMP, enable GC zeal (https://theqwertiest.github.io/foo_spider_monkey_panel/docs/for_developers/component_development_tips/#test-with-gczeal) and see if the memory leak is still there.
Note: GC zeal will tank the performance, so it might take some time for the script to load.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #471
@snotlicker , fixed in the Nightly build.

@MordredKLB , I've fixed the `ghost tooltip` in the Nightly build. Can you check if it fixes your memory leak as well?

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #472
@snotlicker , fixed in the Nightly build.

@MordredKLB , I've fixed the `ghost tooltip` in the Nightly build. Can you check if it fixes your memory leak as well?
JFC, it was the god damned tooltip! Now I can spam the Reload() button on my theme, get memory up to 500MB, and it drops back down to 225-230ish within a few seconds. Also easy to verify since if I cause an error in the theme, memory usage drops back to a flat 207MB every time.

I can't believe it. Ghost tooltip issue is also fixed. Thanks so much. :)

 

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #473
Not to be one of those people, but I noticed that ESR 78.x was released a few days ago. How difficult is the jump from 68 to 78? I wouldn't have even noticed, but I was rewriting some of my stuff using the class syntax and found out that I got a "fields are not currently supported" crash when trying to use class field notation. No big deal at all, I was just surprised to discover that the ESRs only release once a year or so.

One other question I've got, I've added the foo_spider_monkey_panel.js to my VSCode project, and it picks up types correctly for everything except window which gives me the following type error for every method: "Property 'RepaintRect' does not exist on type 'Window & typeof globalThis'." Any way around that?

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #474
How difficult is the jump from 68 to 78?
Dunno. SM devs do not care much for API stability (or MSVC compatibility), so it might be anything between a simple SM recompile or a full-blown SMP rewrite.
Anyway, I won't start migrating to ESR78 before I finish the ConfigureV2 rewrite (which will take a loooong time).

Any way around that?
The problem is that `window` object is a built-in JS object, which causes conflicts with SMP definitions.
There *is* probably a way to work around that, but I don't have any ideas =)
PS: If you *do* find a workaround, plz message me, so I could add it to the docs.