1. 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
2. RE: Help with plugin concept
> -----Original Message-----
> From: Judith Evans [mailto:camping at txcyber.com]
> To: Eu Forum
> Subject: Help with plugin concept
>
>
>
> 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?
>
You have some important design considerations to settle on first.
Do you want a plugin to be 'registered' when the IDE starts (the "include"
method) or after it starts (via some type of load method)?
The "include" method means that either someone needs to alter your code or
must stick to a specific file naming convention so your code can 'hard-code'
the include file name.
The "load" method means that the plugin cannot be Euphoria code AND run in
the same process space as the IDE. If you want it to run in the IDE's
process, it needs to be a runtime-loadable file such as a DLL. If you want
it to be interpretred Euphoria code, you could start up a new instance of
Euphoria to run it in its own process space and then communicate with it via
Inter-Process-Communications API.
Each decision has its own good points and bad points. At some stage you need
to make concessions/trade-offs.
My choice would be to have plugins run in their own process space and use an
IPC to pass data between the IDE and the plugin.
After you have made this decision, you then have to develop a protocol or
API that the plugin writer can use. The plugin writer needs to know how the
IDE will communicate etc...
This is not a trival task. I believe Mario Steele has got some experience
with making this concept work with Euphoria programs.
--
Derek
3. RE: Help with plugin concept
This is exactly why i wanted "eval" type commands.
http://www.topica.com/lists/EUforum/read/message.html?mid=1715848930&sort=d&start=28405
Derek Parnell wrote:
>
>
> > -----Original Message-----
> > From: Judith Evans [mailto:camping at txcyber.com]
> > Sent: Friday, 13 February 2004 9:42 AM
> > To: Eu Forum
> > Subject: Help with plugin concept
> >
> >
> > 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?
> >
>
> You have some important design considerations to settle on first.
>
> Do you want a plugin to be 'registered' when the IDE starts (the
> "include"
> method) or after it starts (via some type of load method)?
>
> The "include" method means that either someone needs to alter your code
> or
> must stick to a specific file naming convention so your code can
> 'hard-code'
> the include file name.
>
> The "load" method means that the plugin cannot be Euphoria code AND run
> in
> the same process space as the IDE. If you want it to run in the IDE's
> process, it needs to be a runtime-loadable file such as a DLL. If you
> want
> it to be interpretred Euphoria code, you could start up a new instance
> of
> Euphoria to run it in its own process space and then communicate with it
> via
> Inter-Process-Communications API.
>
> Each decision has its own good points and bad points. At some stage you
> need
> to make concessions/trade-offs.
>
> My choice would be to have plugins run in their own process space and
> use an
> IPC to pass data between the IDE and the plugin.
>
> After you have made this decision, you then have to develop a protocol
> or
> API that the plugin writer can use. The plugin writer needs to know how
> the
> IDE will communicate etc...
>
> This is not a trival task. I believe Mario Steele has got some
> experience
> with making this concept work with Euphoria programs.
>
> --
> Derek
>
>
4. RE: Help with plugin concept
> -----Original Message-----
> From: Igor Kachan [mailto:kinz at peterlink.ru]
> Subject: Re: Help with plugin concept
>
>
[snip]
>
> Why not?
> Works for me ...
This and Aku's suggestion only works for interpreted Euphoria. It will not
work for a compiled IDE.
And there is no guarentee that it will work for future versions as it is an
undocumented trick and new versions of Euphoria might not support it.
--
Derek
5. RE: Help with plugin concept
Derek Parnell wrote:
>
>
> > From: Judith Evans [mailto:camping at txcyber.com]
> >
> > I've been working on a plugin for IDE as a test of concept.
>
> You have some important design considerations to settle on first.
>
>
> The "load" method means that the plugin cannot be Euphoria code AND
> run in the same process space as the IDE. If you want it to run in
> the IDE's process, it needs to be a runtime-loadable file such as a
> DLL.
You could use my WinDLL library (www.rapideuphoria.com/windll.zip) to
accomplish this. You'll need to add your IDE API to the list of
functions and procedures in windll.ew and windll_c.ew, plus add the
wrapper in windll_c.ew. Let me know if you have questions.
One interesting effect of this is that you can develop the plug-in by
adding an include file within the IDE, and then take it out and compile,
and it should run the same (assuming that you've initialized all
routines and all accessed variables through retrieve() ).
Matt Lewis
6. RE: Help with plugin concept
Robert Craig 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.
>
> 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.
>
i think that widgets by jiri babor might be useful as that new language
construct or mini-API
> 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
>
>
lotterywars
7. RE: Help with plugin concept
See my message(if it ever appears!)
Kat wrote:
>
>
> 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
>
8. RE: Help with plugin concept
By using an "eval()" type function as in:
http://www.topica.com/lists/EUforum/read/message.html?mid=1716043152&sort=d&start=28878
would work very good for plugins, and many other things.
Juergen Luethje wrote:
>
>
> 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
>
