Xojo Conferences
XDCMay2019MiamiUSA

FR: Plugin debug load mode (Real Studio Plugins Mailinglist archive)

Back to the thread list
Previous thread: 3.1pr4
Next thread: plugin prop setter question


Re: Mail Errors [was Re: New Plugins SDK Available]   -   Jan Erik Moström <
  FR: Plugin debug load mode   -   Christian Schmitz
   Re: FR: Plugin debug load mode   -   Alfred Van Hoek
    Re: FR: Plugin debug load mode   -   Einhugur Software
    Re: FR: Plugin debug load mode   -   Christian Schmitz
   Re: FR: Plugin debug load mode   -   Joseph J. Strout
    Re: FR: Plugin debug load mode   -   Christian Schmitz

FR: Plugin debug load mode
Date: 18.01.03 18:18 (Sat, 18 Jan 2003 18:18:35 +0100)
From: Christian Schmitz
Hi,

Please RS, add to the next beta or better even for all new version a
switch (in Preferences or maybe shift on RB launch) so that the IDE
prints out debug information for loading plugins.

I'd like to see something on the console window like this:

Opening file "Monkeybread Software Plugin"
Loading plugin ID 128 (PLCN *1)
Loading plugin ID 129 (PLCN)
Loading plugin ID 130 (PLCN)
Loading plugin ID 131 (PLCN)
Loading plugin ID 132 (PLCN)
...
Loaded 80 code fragments from file "Monkeybread Software Plugin"
Processing plugin ID 128 (PLCN *1)
Processing plugin ID 129 (PLCN)
Processing plugin ID 130 (PLCN)
Processing plugin ID 131 (PLCN)
...
Processed 80 plugins.
...

*1 you could add the name of the resource here

This way we could exactly see which plugin is crashing in our plugin
folder.

Also it should be checked for some things:

1. reserved words
2. no byref in functions (doesn't work in RB 4.5, not sure for Rb5)
3. If a lib is missing to load a plugin, print it.
4. Check if plugin resource is correct
(PPC has native header, Carbon has no resource header)
5. Check if icons are there for the controls toolbar images.

Maybe someone has more ideas.

PS: this is nothing to enter in the bug database, because RS must do
something like this within next week if they really want plugin
developers to support Rb5.

Mfg
Christian

Re: FR: Plugin debug load mode
Date: 18.01.03 20:04 (Sat, 18 Jan 2003 14:04:27 -0500)
From: Alfred Van Hoek
on 1/18/03 12:18 PM, Christian Schmitz at <email address removed>
wrote:

Don't think this will really help, if you are concerned. I agree with you
and Björn more info is required how to set up the new plugin format; If
only one example would be available from RS, it certainly would help to
communicate the difficulties in a bit more constructive way. I also admit,
that I have been disappointed during the alpha cycle and indicated this too.

> *1 you could add the name of the resource here
>
> This way we could exactly see which plugin is crashing in our plugin
> folder.
Can't you do this yourself, isn't this something plugin developers always
have to do to get a plugin do the things it expects to do?
>
> Also it should be checked for some things:
>
> 1. reserved words
> 2. no byref in functions (doesn't work in RB 4.5, not sure for Rb5)

You mean a byref in a global function right?

> 3. If a lib is missing to load a plugin, print it.

Isn't this up to the plugin developer?, How should RB know what lib is
required? It's the plug that should know it.

> 4. Check if plugin resource is correct
> (PPC has native header, Carbon has no resource header)

Why?

> 5. Check if icons are there for the controls toolbar images.

Why again.., this is up to the plugin author

>
> Maybe someone has more ideas.

For every plugin-resource to load you can setup a function like:

void Register_ByteRangeClass(void)
{
REALRegisterClass(&ByteRangeClass);
}

and call Register_ByteRangeClass in the PluginEntry. You can modify
Register_ByteRangeClass to setup some flags and output this in the
console...
>
> PS: this is nothing to enter in the bug database, because RS must do
> something like this within next week if they really want plugin
> developers to support Rb5.

The problem I see is that you haven't indicated the exact problem(s) you
face. I remember Björn posted a while ago that when a plug has a couple of
codefragments with unique id's when non-contiguous, RB stops loading those
fragments because it thinks no additional resources are available:

Thus
plugID 128
plugID 129
plugID 130 <--- stops here
plugID 141
plugID 142

So this would explain one of your problems after removing some of your
plugin "parts".

Because you indicated a similar bug as Ruslan reported, I assumed then that
a bug with an array as argument would exist in RB5.

5b1 is the first release to accomplish a little bit with some of my plugins.
I haven't experienced the crash you and Ruslan indicate, and I wouldn't know
how to reproduce it until you could give better info. The crashlog does not
say much, and I doubt RS can figure this either. Is it because you've got a
number of cfm's with different resourceIDs or not?

Alfred

---
A searchable archive of this list is available at:
<http://support.realsoftware.com/KBDB/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: FR: Plugin debug load mode
Date: 18.01.03 21:15 (Sat, 18 Jan 2003 20:15:01 +0000)
From: Einhugur Software

On Laugardagur, jan 18, 2003, at 19:04 Etc/GMT, Alfred Van Hoek wrote:

> The problem I see is that you haven't indicated the exact problem(s)
> you
> face. I remember Björn posted a while ago that when a plug has a
> couple of
> codefragments with unique id's when non-contiguous, RB stops loading
> those
> fragments because it thinks no additional resources are available:
>
> Thus
> plugID 128
> plugID 129
> plugID 130 <--- stops here
> plugID 141
> plugID 142

This problem is actually, if a 68k code segment is missing in the
middle:

So if a plugin has:

68k PPC Carbon
128 128 128
129 129 129
Missing 130 130
131 131 131

Then when running in Carbon it will stop loading after 129 because 68k
is missing.
(Don't know if this is in the 5, but I could sometimes still get it in
4.5)

I reported this bug from the first RB Carbon version several times, but
of course that had no affect as usually with something regarding
plugins.
-

Re: FR: Plugin debug load mode
Date: 19.01.03 00:33 (Sun, 19 Jan 2003 00:33:14 +0100)
From: Christian Schmitz
> > *1 you could add the name of the resource here
> >
> > This way we could exactly see which plugin is crashing in our plugin
> > folder.
> Can't you do this yourself, isn't this something plugin developers always
> have to do to get a plugin do the things it expects to do?

Sure, but Think Different. Codewarrior has some debug output for
plugins, as I recenty saw.
Why could not RB have it?

> > Also it should be checked for some things:
> >
> > 1. reserved words
> > 2. no byref in functions (doesn't work in RB 4.5, not sure for Rb5)
>
> You mean a byref in a global function right?

Yes. It crashes, so I don't use it, even if it may be fixed now.

> > 3. If a lib is missing to load a plugin, print it.
>
> Isn't this up to the plugin developer?, How should RB know what lib is
> required? It's the plug that should know it.

The CodeFragment Manager gives you a human readable error message. I'd
like to see them.
Same on Windows for DLL loading. You get the name of the missing one.

> > 4. Check if plugin resource is correct
> > (PPC has native header, Carbon has no resource header)
>
> Why?

Because I had a lot of crashes with this.

> > 5. Check if icons are there for the controls toolbar images.
>
> Why again.., this is up to the plugin author

"never trust user input"
RB should check if the plugins are okay...
(I was missing a fifth point ;-)

> > Maybe someone has more ideas.
>
> For every plugin-resource to load you can setup a function like:
>
> void Register_ByteRangeClass(void)
> {
> REALRegisterClass(&ByteRangeClass);
> }
>
> and call Register_ByteRangeClass in the PluginEntry. You can modify
> Register_ByteRangeClass to setup some flags and output this in the
> console...

For what?
As I see it, RB loads the plugins and after they are loaded it does some
magic around the definitions.

> The problem I see is that you haven't indicated the exact problem(s) you
> face.

Because I don't know what RB5 does.
the 80 plugins plugin crashes RB.
But if I remove one of them it ignores the plugin.

> I remember Björn posted a while ago that when a plug has a couple of
> codefragments with unique id's when non-contiguous, RB stops loading those
> fragments because it thinks no additional resources are available:

Oh yes. When I delete the Controls plugin part, it loads only the first
6 plugins. (RB5b1)
If I delete the PLPC resource matching the Carbon plugin, I go back to
the crash.

> So this would explain one of your problems after removing some of your
> plugin "parts".

Yes.

> Because you indicated a similar bug as Ruslan reported, I assumed then that
> a bug with an array as argument would exist in RB5.

So I removed all four plugin parts which uses arrays and the plugin
loads!

Mfg
Christian

-

Re: FR: Plugin debug load mode
Date: 18.01.03 22:13 (Sat, 18 Jan 2003 13:13:29 -0800)
From: Joseph J. Strout
At 6:18 PM +0100 1/18/03, Christian Schmitz wrote:

>Please RS, add to the next beta or better even for all new version a
>switch (in Preferences or maybe shift on RB launch) so that the IDE
>prints out debug information for loading plugins.

That's a good idea.

>PS: this is nothing to enter in the bug database, because RS must do
>something like this within next week if they really want plugin
>developers to support Rb5.

If you really want us to add it in the next week, then you'd better
put it in the feedback system. It's Saturday; none of us will be
working today or tomorrow. Three days and a thousand NUG messages
later, we might well forget unless it's in the system.

Cheers,
- Joe

Re: FR: Plugin debug load mode
Date: 18.01.03 22:26 (Sat, 18 Jan 2003 22:26:54 +0100)
From: Christian Schmitz
> If you really want us to add it in the next week, then you'd better
> put it in the feedback system.

Let's talk about it and on sunday evening, I hope I add it.

mfg
Christian