1. Help with plugin concept

Experts, I need some advice.

I've been working on a plugin for IDE as a test of concept. I've worked up
the first plugin which will open a window in Code Editor to view code
statements for all windows/controls in the order exw would generate them. It
all works very nice as long as in IDE.exw I hard-code the statement "include
ViewCodeBase.plg". Since I will never know the plugin file names the users
write for IDE or even if user is using any, what I wanted to do was place
the plugin files in a subfolder named Plugins. After all the include
statements in IDE.exw I wanted to read the Plugins folder and add an include
statement for each file name found as follows:

--get includes from plugin folder
object files

files=dir(the_current_dir & "//Plugins")
if sequence(files) then
    if length(files) then
        for i=1 to length(files) do
            if not equal("d",files[i][D_ATTRIBUTES]) then
              include viewCodeBase.plg    <=== gets ex.err
            end if
        end for
    end if
end if

Ha. I forgot Euphoria would not allow the include statement except at the
highest level. So am I out of luck? Any idea how to get around the problem?

~judith

new topic     » topic index » view message » categorize

2. Re: Help with plugin concept

Hello Judith,

----------
> From: Judith Evans <camping at txcyber.com>
> To: Eu Forum <EUforum at topica.com>
> Subject: RE: Help with plugin concept
> 
> 
> The corrected routine is below but it doesn't 
> really matter because it will never work.
> 
> files=dir(the_current_dir & "//Plugins")
> if sequence(files) then
>     if length(files) then
>         for i=1 to length(files) do
>             if not equal("d",files[i][D_ATTRIBUTES]) then
> --corrected line
>               include files[i][D_NAME]    <=== gets ex.err
> -----------------------------------
>             end if
>         end for
>     end if
> end if

Try please:

-- code
include file.e

object files

sequence PluginS
integer P_S

PluginS={}

files = dir(current_dir()) -- & "//Plugins") -- just to test, any files
if sequence(files) then
    if length(files) then
	for i=1 to length(files) do
	    if not equal("d",files[i][D_ATTRIBUTES]) then
 --            include files[i][D_NAME]    <=== gets ex.err
   PluginS &= "include " & files[i][D_NAME] & "\n"  --<-- this is a clue
	    end if
	end for
    end if
end if

P_S = open ("plugins.ew", "wb")
 puts(P_S, PluginS)
close(P_S)

include plugins.ew
-- end of code

Why not?
Works for me ...

Good Luck!

Regards,
Igor Kachan
kinz at peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

3. Re: Help with plugin concept

Hello Derek,

----------
> From: Derek Parnell <ddparnell at bigpond.com>
> Subject: RE: Help with plugin concept
> > -----Original Message-----
> > From: Igor Kachan [mailto:kinz at peterlink.ru]
> > Sent: Friday, 13 February 2004 7:29 PM
> > To: EUforum at topica.com
> > Subject: Re: Help with plugin concept
> >
> >
> [snip]
> 
> >
> > Why not?
> > Works for me ...

> This and Aku's suggestion only works 
> for interpreted Euphoria. 

If you want to compile IDE with *the current set of plugins*
it will work compiled.

> It will not work for a compiled IDE.

Judith doesn't want to compile IDE now,
it seems to be, I think smile
And this way is really good and very good,
this way is the Open Source way, MS opens
their sources, I heard ... No? Open Windows!

> And there is no guarentee that it will work for 
> future versions as it is an undocumented trick

Well, ask Rob to document this trick as sometimes useful, no
protests. But it is documented in our list archive, let us 
read archive, why Rob must document, document and document
these tricks?
 
> and new versions of Euphoria might not support it.

There is no any reason to abandon the support 
of the main Euphoria functions.

Another thing, if Judith wants to add the plugins feature
into her IDE, it may require the detailed specification for
the plugins as to the special include files, as you mentioned
in your e-mail, Derek, and that work is not trivial, yes.

> --
> Derek

Regards,
Igor Kachan
kinz at peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

4. Re: Help with plugin concept

Hello Matt,

----------
> From: Matt Lewis <matthewwalkerlewis at yahoo.com>
> Subject: RE: Help with plugin concept

[snipped]

> I typically use Open Watcom 1.0, but 
> it's something like a 50MB download.

There is Open Watcom 1.2 on their site now.
Many new things and fixes.

[snipped]

Regards,
Igor Kachan
kinz at peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

5. Re: Help with plugin concept

The trick where a Euphoria program modifies an include file
just before including it, does not work with the translator
or the binder, and in the next release it won't work with
the interpreter either.

We may eventually need some new language construct
in this area, but currently you can easily convert
Euphoria code to a .dll, and you can pass Euphoria data
(atoms and sequences) to it, and get Euphoria data returned.
The only problem is, as with all .dlls, you can't easily
share your global variables. You'd have to define a
kind of mini-API, that the .dll (plugin) authors would support.

You can also, of course, run a separate Euphoria program,
via system() etc., and communicate with it via files,
or maybe even shared memory.

Regards,
    Rob Craig
    Rapid Deployment Software
    http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

6. Re: Help with plugin concept

Hello Robert,

----------
> From: Robert Craig <rds at RapidEuphoria.com>
> Subject: Re: Help with plugin concept

You wrote:

> The trick where a Euphoria program modifies an include file
> just before including it, does not work with the translator
> or the binder, and in the next release it won't work with
> the interpreter either.

Please, couldn't you explain more detailed what do you 
mean when you say it does not work and it won't work. 
What a reason ?

It worked and works for me in 2.3 and in 2.4 with ec and bind.
Maybe my tests are wrong or incomplete?

I run interpreted program to create the resulting include
file then run binder or translator with *ready* resulting
include file and *it works*.

[snipped]
 
Regards,
Igor Kachan
kinz at peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

7. Re: Help with plugin concept

Igor Kachan wrote:
 > Please, couldn't you explain more detailed what do you
 > mean when you say it does not work and it won't work.
 > What a reason ?

The example code that you posted was...

     P_S = open ("plugins.ew", "wb")
     puts(P_S, PluginS)
     close(P_S)

     include plugins.ew

The above code depends on the open() and puts() taking place
before the include is processed. With the current
interpreter that's what happens. With the current
binder and translator that's not what happens.
Rather, the binder and translator process the include file
(and all other source code) first. Execution of statements
happens later at run-time, when it's too late
for the open/puts to have the desired effect.

In the next release, with the clearer separation between
front-end and back-end, the interpreter will also
process the include (and all other source)
before it executes any code.
It will be simpler this way. I don't think a lot of
people are actually using the above "dynamic" include
technique, although it has been discussed on this list
from time to time.

 > I run interpreted program to create the resulting include
 > file then run binder or translator with *ready* resulting
 > include file and *it works*.

That's fine. You are first running a program that creates
an include file, then *in a separate step* you are using that
include file for translating or binding. However, the users
of your program might not have the translator or binder,
and even if they did, they might not want to run it.

Status:
Currently, I have built:
   - a new front-end (written 100% in Euphoria)
   - a new back-end for the translator (100% in Euphoria)
   - a backend for the interpreter (100% in Euphoria)

I am working on attaching the current C-written back-end
to the new Euphoria-written front-end.

I have extensively tested the new translator
(100% in Euphoria) and it appears to work flawlessly,
as well as being pretty fast.

I now have a Euphoria interpreter written 100% in Euphoria.
It runs all Euphoria programs perfectly (as far as I know),
though it's slower of course. It can even run itself.
I tried running itself, running itself, running itself,
running a small program, and it worked fine, although it
was extremely slow. I'm not sure yet what I'll do with it.
It was extremely easy to implement.

I can translate the Euphoria-written interpreter to make it faster.
I can interpret or translate the new translator. Both can
handle the largest programs, such as Judith's IDE.

Regards,
    Rob Craig
    Rapid Deployment Software
    http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

8. Re: Help with plugin concept

On Fri, 13 Feb 2004 18:58:50 -0500, Robert Craig
<rds at RapidEuphoria.com> wrote:

>Igor Kachan wrote:
> > Please, couldn't you explain more detailed what do you
> > mean when you say it does not work and it won't work.
> > What a reason ?
>
>The example code that you posted was...
>
>     P_S = open ("plugins.ew", "wb")
>     puts(P_S, PluginS)
>     close(P_S)
>
>     include plugins.ew
>
>The above code depends on the open() and puts() taking place
>before the include is processed. With the current
>interpreter that's what happens. With the current
>binder and translator that's not what happens.
>Rather, the binder and translator process the include file
>(and all other source code) first. Execution of statements
>happens later at run-time, when it's too late
>for the open/puts to have the desired effect.
>
>In the next release, with the clearer separation between
>front-end and back-end, the interpreter will also
>process the include (and all other source)
>before it executes any code.
OK. I have no argument with that.
>It will be simpler this way. I don't think a lot of
>people are actually using the above "dynamic" include
>technique, although it has been discussed on this list
>from time to time.
True.

I cannot however resist suggesting (in pseudo code rather than true or
tested Euphoria, you understand):

in say misc.e:
procedure dynamic_include(sequence filename, sequence contents)
integer changed, fn,
object d
	if interpreting or translating then	-- see PS
		changed=0
		d=dir(filename)	--##I forget the syntax/results##
		if d!=-1 and d[SIZE]=length(contents) then
			fn=open(filename,"r")
			for i=1 to length(contents) do
				if getc(fn)!=contents[i] then
					changed=1
					exit
				end if
			end for
			close(fn)
			if changed=0 then return end if
		end if
		open(filename,"w")
		puts(fn,contents)
		close(fn)
		puts(1,"dynamic include changed; restarting...")
		system(command_line())
		abort(0)
	end if
end procedure

then:
dynamic_include(filename,contents)
include filename

Does that make sense?
If so, I don't think it is much work and it will (might) put this
issue to bed once and for all.

Regards,
Pete
PS I am undecided whether it would be better for bind/translate to
simply not generate any code whatsoever for the dynamic_include()
call, or issue a fatal error (/warning) if it detects the program
ought to be re-bound/re-translated.

new topic     » goto parent     » topic index » view message » categorize

9. Re: Help with plugin concept

Robert Craig wrote:

[snipped, thanks for the explanation]

> In the next release, with the clearer separation
> between front-end and back-end, the interpreter 
>  will also process the include (and all other source)
> before it executes any code.

Complete pass from single pass to two and more passes ... 

> It will be simpler this way. I don't think a lot of
> people are actually using the above "dynamic" include
> technique, 

It seems to be ... 

>  although it has been discussed on this list
> from time to time.

It is useful ... And with two passes it requires some functional
replacement
and reorganization of code ...

>  > I run interpreted program to create the resulting include
>  > file then run binder or translator with *ready* resulting
>  > include file and *it works*.
> 
> That's fine. You are first running a program that creates
> an include file, then *in a separate step* you are using that
> include file for translating or binding. However, the users
> of your program might not have the translator or binder,
> and even if they did, they might not want to run it.

Interpreter, translator, binder will give more equal functional results.
Good.
Good reason.

> Status:
> Currently, I have built:
>    - a new front-end (written 100% in Euphoria)
>    - a new back-end for the translator (100% in Euphoria)
>    - a backend for the interpreter (100% in Euphoria)
> 
> I am working on attaching the current C-written back-end
> to the new Euphoria-written front-end.
> 
> I have extensively tested the new translator
> (100% in Euphoria) and it appears to work flawlessly,
> as well as being pretty fast.
> 
> I now have a Euphoria interpreter written 100% in Euphoria.
> It runs all Euphoria programs perfectly (as far as I know),
> though it's slower of course. It can even run itself.
> I tried running itself, running itself, running itself,
> running a small program, and it worked fine, although it
> was extremely slow. I'm not sure yet what I'll do with it.
> It was extremely easy to implement.
> 
> I can translate the Euphoria-written interpreter to make it faster.
> I can interpret or translate the new translator. Both can
> handle the largest programs, such as Judith's IDE.

Thanks Rob.
 
Good Luck.

Regards,
Igor Kachan
kinz at peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

10. Re: Help with plugin concept

Rob wrote:

> Igor Kachan wrote:
>> Please, couldn't you explain more detailed what do you
>> mean when you say it does not work and it won't work.
>> What a reason ?
>
> The example code that you posted was...
>
>      P_S = open ("plugins.ew", "wb")
>      puts(P_S, PluginS)
>      close(P_S)
>
>      include plugins.ew
>
> The above code depends on the open() and puts() taking place
> before the include is processed. With the current
> interpreter that's what happens. With the current
> binder and translator that's not what happens.
> Rather, the binder and translator process the include file
> (and all other source code) first. Execution of statements
> happens later at run-time, when it's too late
> for the open/puts to have the desired effect.
>
> In the next release, with the clearer separation between
> front-end and back-end, the interpreter will also
> process the include (and all other source)
> before it executes any code.
> It will be simpler this way. I don't think a lot of
> people are actually using the above "dynamic" include
> technique, although it has been discussed on this list
> from time to time.
>
>> I run interpreted program to create the resulting include
>> file then run binder or translator with *ready* resulting
>> include file and *it works*.
>
> That's fine. You are first running a program that creates
> an include file, then *in a separate step* you are using that
> include file for translating or binding. However, the users
> of your program might not have the translator or binder,
> and even if they did, they might not want to run it.

<snip>

I believe using the next version of the interpreter, programs still
can take advantage of a dynamic include technique, when the code is
just put into 2 files rather than 1. Then again there are 2 separate
steps:

------------------------[ part1.exw ]------------------------
     P_S = open ("plugins.ew", "wb")
     puts(P_S, PluginS)
     close(P_S)
     system("exw.exe part2.exw", 2)

------------------------[ part2.exw ]------------------------
     include plugins.ew
     -- Here comes the main program ...
-------------------------------------------------------------

This should work with the interpreter 2.5, shouldn't it?

Regards,
   Juergen

new topic     » goto parent     » topic index » view message » categorize

11. Re: Help with plugin concept

Hi Juergen,

----------
> From: Juergen Luethje <j.lue at gmx.de>
> Subject: Re: Help with plugin concept

[snipped] 

> <snip>
> 
> I believe using the next version of the interpreter, programs still
> can take advantage of a dynamic include technique, when the code is
> just put into 2 files rather than 1. Then again there are 2 separate
> steps:
> 
> ------------------------[ part1.exw ]------------------------
>      P_S = open ("plugins.ew", "wb")
>      puts(P_S, PluginS)
>      close(P_S)
>      system("exw.exe part2.exw", 2)
> 
> ------------------------[ part2.exw ]------------------------
>      include plugins.ew
>      -- Here comes the main program ...
> -------------------------------------------------------------
> 
> This should work with the interpreter 2.5, shouldn't it?

Why not? Definitely should with system_exec().

Another way is just .bat file 
(without system_exec() in the first part)
(untested project for 2.5 and better versions :)

@ rem -- code of ide.bat
@ rem -- part1.exw prepares all plugins as common include file
@ exw.exe part1.exw
@ rem -- part2.exw executes IDE with plugins
@ exw.exe part2.exw
@ rem -- end of code

This is EU, isn't it ?

Rob, your move  smile

Regards,
Igor Kachan
kinz at peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

12. Re: Help with plugin concept

Juergen Luethje wrote:
> I believe using the next version of the interpreter, programs still
> can take advantage of a dynamic include technique, when the code is
> just put into 2 files rather than 1. Then again there are 2 separate
> steps:
> 
> ------------------------[ part1.exw ]------------------------
>      P_S = open ("plugins.ew", "wb")
>      puts(P_S, PluginS)
>      close(P_S)
>      system("exw.exe part2.exw", 2)
> 
> ------------------------[ part2.exw ]------------------------
>      include plugins.ew
>      -- Here comes the main program ...
> -------------------------------------------------------------
> 
> This should work with the interpreter 2.5, shouldn't it?

Yes.

Igor Kachan wrote:
> Another way is just .bat file 
> (without system_exec() in the first part)
> (untested project for 2.5 and better versions 
> 
> @ rem -- code of ide.bat
> @ rem -- part1.exw prepares all plugins as common include file
> @ exw.exe part1.exw
> @ rem -- part2.exw executes IDE with plugins
> @ exw.exe part2.exw
> @ rem -- end of code
> 
> This is EU, isn't it ?

Yes, that will work too.

Regards,
    Rob Craig
    Rapid Deployment Software
    http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

13. Re: Help with plugin concept

Pete Lomax wrote:
> I cannot however resist suggesting (in pseudo code rather than true or
> tested Euphoria, you understand):
> 
> in say misc.e:
> procedure dynamic_include(sequence filename, sequence contents)
> integer changed, fn,
> object d
> 	if interpreting or translating then	-- see PS
> 		changed=0
> 		d=dir(filename)	--##I forget the syntax/results##
> 		if d!=-1 and d[SIZE]=length(contents) then
> 			fn=open(filename,"r")
> 			for i=1 to length(contents) do
> 				if getc(fn)!=contents[i] then
> 					changed=1
> 					exit
> 				end if
> 			end for
> 			close(fn)
> 			if changed=0 then return end if
> 		end if
> 		open(filename,"w")
> 		puts(fn,contents)
> 		close(fn)
> 		puts(1,"dynamic include changed; restarting...")
> 		system(command_line())
> 		abort(0)
> 	end if
> end procedure
> 
> then:
> dynamic_include(filename,contents)
> include filename
> 
> Does that make sense?
> If so, I don't think it is much work and it will (might) put this
> issue to bed once and for all.
> 
> Regards,
> Pete
> PS I am undecided whether it would be better for bind/translate to
> simply not generate any code whatsoever for the dynamic_include()
> call, or issue a fatal error (/warning) if it detects the program
> ought to be re-bound/re-translated.

That's an interesting idea.
A bit convoluted though.
I think I'll wait and see if anyone starts
screaming about this issue when the new interpreter
is released.

Regards,
    Rob Craig
    Rapid Deployment Software
    http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

14. Re: Help with plugin concept

On 14 Feb 2004, at 13:45, Robert Craig wrote:

> 
> 
> Pete Lomax wrote:
> > I cannot however resist suggesting (in pseudo code rather than true or
> > tested Euphoria, you understand):
> > 
> > in say misc.e:
> > procedure dynamic_include(sequence filename, sequence contents)
> > integer changed, fn,
> > object d
> > 	if interpreting or translating then	-- see PS
> > 		changed=0
> > 		d=dir(filename)	--##I forget the syntax/results##
> > 		if d!=-1 and d[SIZE]=length(contents) then
> > 			fn=open(filename,"r")
> > 			for i=1 to length(contents) do
> > 				if getc(fn)!=contents[i] then
> > 					changed=1
> > 					exit
> > 				end if
> > 			end for
> > 			close(fn)
> > 			if changed=0 then return end if
> > 		end if
> > 		open(filename,"w")
> > 		puts(fn,contents)
> > 		close(fn)
> > 		puts(1,"dynamic include changed; restarting...")
> > 		system(command_line())
> > 		abort(0)
> > 	end if
> > end procedure
> > 
> > then:
> > dynamic_include(filename,contents)
> > include filename
> > 
> > Does that make sense?
> > If so, I don't think it is much work and it will (might) put this
> > issue to bed once and for all.
> > 
> > Regards,
> > Pete
> > PS I am undecided whether it would be better for bind/translate to
> > simply not generate any code whatsoever for the dynamic_include()
> > call, or issue a fatal error (/warning) if it detects the program
> > ought to be re-bound/re-translated.
> 
> That's an interesting idea.
> A bit convoluted though.
> I think I'll wait and see if anyone starts
> screaming about this issue when the new interpreter
> is released.

<scream><scream><scream><scream><scream><scream><scream><scre
am><scream><scream><scream><scream><scream><scream><scream><
scream><scream>

It's things like this, and executing vars and such, that made me drop Eu for a 
number of things. You could just as easily encorporate dynamic includes as:

var = fget("filename.e")
function1 = var[50..2000]
function2 = var[2010..3000]

or 

execute(var)

But heck, i have been screaming for these things for years, i am now using 
PHP to get around Eu deficiencies, especially on nix boxes. You may be 
deciding on what the language can do based on the number of people asking 
for them, but you won't hear from those who just decide you won't add them 
anyhow, and politely quietly move on to other languages. At least i said 
something first, repeatedly. People won't use it if they must first ask for 
features, wait years, and then see if they get the features. Or get Karl to add 
it to his language in a few days.

Kat

new topic     » goto parent     » topic index » view message » categorize

15. Re: Help with plugin concept

The only problem with this method of plugins....

The resulting IDE is still monolithic... let me explain:

If you load/install a 3rd party plugin for your ide, that is missing an 
external include, or has bugs...

Then prg2.exw, or whatever you call it, will crash. And the user will not 
necissarily know what has happened, and unless the plugin installer-loader 
is separate from the main ide, there is not a user-level way to unload it.

I know that the trickery that you have described will work, as long as all 
the plugins are perfectly working. However, for a more robust ide, the idea 
of dll's and an API is much better, as it allows for some kind of "This 
plugin could not load" message, and for the IDE to continue functioning.

Unless of course, Rob allowed an "include(sequence file)" function, that 
returned either 0 for success, or an error code showing how the include 
failed... It's ok Rob, maybe for Eu2.6

;oP


MrTrick


>From: Robert Craig <rds at RapidEuphoria.com>
>Reply-To: EUforum at topica.com
>To: EUforum at topica.com
>Subject: Re: Help with plugin concept
>Date: Sat, 14 Feb 2004 12:50:59 -0500
>
>
>Juergen Luethje wrote:
>>I believe using the next version of the interpreter, programs still
>>can take advantage of a dynamic include technique, when the code is
>>just put into 2 files rather than 1. Then again there are 2 separate
>>steps:
>>
>>------------------------[ part1.exw ]------------------------
>>      P_S = open ("plugins.ew", "wb")
>>      puts(P_S, PluginS)
>>      close(P_S)
>>      system("exw.exe part2.exw", 2)
>>
>>------------------------[ part2.exw ]------------------------
>>      include plugins.ew
>>      -- Here comes the main program ...
>>
>>This should work with the interpreter 2.5, shouldn't it?
>
>Yes.
>
>Igor Kachan wrote:
>>Another way is just .bat file (without system_exec() in the first part)
>>(untested project for 2.5 and better versions
>>
>>@ rem -- code of ide.bat
>>@ rem -- part1.exw prepares all plugins as common include file
>>@ exw.exe part1.exw
>>@ rem -- part2.exw executes IDE with plugins
>>@ exw.exe part2.exw
>>@ rem -- end of code
>>
>>This is EU, isn't it ?
>
>Yes, that will work too.
>
>Regards,
>    Rob Craig
>    Rapid Deployment Software
>    http://www.RapidEuphoria.com
>
>
>
>TOPICA - Start your own email discussion group. FREE!
>
>

new topic     » goto parent     » topic index » view message » categorize

16. Re: Help with plugin concept

Patrick Barnes wrote [quotations rearranged]:

>> From: Robert Craig
>> Date: Sat, 14 Feb 2004 12:50:59 -0500
>>
>> Juergen Luethje wrote:
>>> I believe using the next version of the interpreter, programs still
>>> can take advantage of a dynamic include technique, when the code is
>>> just put into 2 files rather than 1. Then again there are 2 separate
>>> steps:
>>>
>>> ------------------------[ part1.exw ]------------------------
>>>       P_S = open ("plugins.ew", "wb")
>>>       puts(P_S, PluginS)
>>>       close(P_S)
>>>       system("exw.exe part2.exw", 2)
>>>
>>> ------------------------[ part2.exw ]------------------------
>>>       include plugins.ew
>>>       -- Here comes the main program ...
>>>
>>> This should work with the interpreter 2.5, shouldn't it?
>>
>> Yes.
>>
>> Igor Kachan wrote:
>>> Another way is just .bat file (without system_exec() in the first part)
>>> (untested project for 2.5 and better versions
>>>
>>> @ rem -- code of ide.bat
>>> @ rem -- part1.exw prepares all plugins as common include file
>>> @ exw.exe part1.exw
>>> @ rem -- part2.exw executes IDE with plugins
>>> @ exw.exe part2.exw
>>> @ rem -- end of code
>>>
>>> This is EU, isn't it ?
>>
>> Yes, that will work too.
>
>
> The only problem with this method of plugins....
>
> The resulting IDE is still monolithic... let me explain:
>
> If you load/install a 3rd party plugin for your ide, that is missing an
> external include, or has bugs...
>
> Then prg2.exw, or whatever you call it, will crash. And the user will not
> necissarily know what has happened, and unless the plugin installer-loader
> is separate from the main ide, there is not a user-level way to unload it.
>
> I know that the trickery that you have described will work, as long as all
> the plugins are perfectly working. However, for a more robust ide, the idea
> of dll's and an API is much better, as it allows for some kind of "This
> plugin could not load" message, and for the IDE to continue functioning.
>
> Unless of course, Rob allowed an "include(sequence file)" function, that
> returned either 0 for success, or an error code showing how the include
> failed... It's ok Rob, maybe for Eu2.6
>
> ;oP

Derek already wrote something about different types of plugins.

When a plugin is a DLL, a serious bug also can cause a program crash.

As I understand it, "API" is a general expression, i.e. this term does
not only refer to DLLs. I think any program, that wants to utilize 3rd
party plugins, should provide an API, regardlesss what way the plugins
are technically implemented.
For example Judith can say, that any plugin should have a function
called plugin_id() that returns say Judith's birthday times PI or
whatever. If the function returns a different value, the main program
can raise a "File 'xyz' is not a proper plugin." message.

If the main program calls a routine in the plugin that does not exist,
the program will crash, regardless wether the plugin is an interpreted
EXW file, or a DLL. In this situation a crash can be prevented by using
the routine_id() technique, and this will work with interpreted EXW
files as well as with DLLs.

Please notice that these are just some general considerations. I don't
want to recommend anything concerning plugins, because I've little
experience in this field.

Regards,
   Juergen

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu