Emerald Editor Discussion
May 27, 2017, 10:18:09 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: 1 [2] 3
  Print  
Author Topic: Plug-in ability  (Read 21394 times)
0 Members and 1 Guest are viewing this topic.
awmyhr
Senior Miner
***
Posts: 95

Maintainer of Obscure and Unused Ports


WWW
« Reply #15 on: June 01, 2006, 12:15:03 pm »

daemon, your insight is invaluable.  I'm not married to Lua, and am more then happy to discuss other alternatives, I would just prefer to avoid a system which creates platform specific parts of the program (or plug-ins).
Logged

-->>  This Space 4 Rent  <<--
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #16 on: June 01, 2006, 05:16:01 pm »

The only reason I was plugging Lua here was because it seems to be the one everyone was plugging for it.

OK, it is an extra internal dependence, but from your post it would seem that Swig is a binder to PHP etc. which seems to me to require the external dependencies of PHP, Perl et al - since some people will prefer using Perl, some will prefer PHP and so on.

While people like us may be happy to install these dependencies, it will become an issue for others - especially those using thumb drives.

Lua seemed to fit the bill, really, by being embeddable and its own language.
Logged

"Cleverly disguised as a responsible adult!"
Wraithan
Prospector
*
Posts: 9


« Reply #17 on: June 01, 2006, 10:08:22 pm »

Arantor, your arguments fit you, but I can code in C++ faster than I can in almost any other language, and with a halfassed logger debugging is easy too. Also your slightly slower is skewed also, there are 2 ways that scripting languages get implemented. First is compiled to a form of bytecode and ran from there, second is parsing and running it from the original text. Compiling to bytecode is faster runtime but slower load time, and the other is just slow, slightly better load times. C++ is compiled once per platform, and distributed. Java shouldn't even be a consideration, RTEs slow things down, a lot.

I don't know what Swig is, but I will take a look at it. It is still a scripting interface, so it will have many limitations that compiled plugins wont.

Some more scatterbrained input:

A couple programs I have used, allow for compiled plugins (since they are faster take less memory and have lower level access generally), and also scripted plugins(which the general public can write easier).
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #18 on: June 01, 2006, 11:08:09 pm »

I admit I'm biased - but that is, at the moment, through lack of knowledge.

As I have admitted in the forums I am not a C++ programmer myself so I am not aware of the implementation side of things to any great depth, and I have never tried writing a scripting language interpretor, so the whole parsing/bytecode argument missed me a bit.

I'm just trying to find a solution that everyone will be content with - I know whatever we do will upset somebody, but Lua seemed to have everything going for it. From my limited knowledge, Swig seems to be an interpreter which has a dependence in the other packages, but I have not installed or used Swig myself (it is installed with Python on the server, however, as a dependence for ViewVC, although to be honest I just used Ubuntu's apt-get to install it as part of the Subversion install I did)

I like the sound of the compiled/non-compiled option, though. It sounds as though it might play a part in EE.
Logged

"Cleverly disguised as a responsible adult!"
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #19 on: June 02, 2006, 05:55:55 am »

After doing more research, I think our best bet is Tcl or AngelScript. For Tcl, we can use Swig to generate the Tcl protos and then imbed a Tcl interpreter (which is small) into our application. With AngelScript, there's minimal programming changes to be done and just a library to link.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #20 on: June 02, 2006, 12:20:56 pm »

Both look like the sort of thing we want. The one thing I would add, though, to either of these is that we should be able to build a binary with no external dependencies, or at least no libraries that are unreasonable or onerous to link to.

For example, a library which must be copied to the Windows directory (on a Windows build) is no good since one of the most requested features is to be self-contained and run from a USB Key, which means few extra dependencies/libraries where possible.

Plus, adding any non-embeddable libraries means extra dependencies that are required for users building their own.

If Tcl can be embedded without requiring Swig to run (i.e. required for building only, perhaps) then it sounds good.
Logged

"Cleverly disguised as a responsible adult!"
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #21 on: June 02, 2006, 11:53:06 pm »

Yes, any of these will be compiled into a static library and linked into EE that way.

And Swig is merely a code generator. When you run Swig, it looks at all your classes and functions and then creates wrapper code that is then compiled into the hooks for the target language.
Logged
awmyhr
Senior Miner
***
Posts: 95

Maintainer of Obscure and Unused Ports


WWW
« Reply #22 on: June 03, 2006, 12:46:20 am »

I do like what I see with AngelScript, and it should make the c/c++ crowd at least a little happy.  Though TCL is more popular, having to use it AND swig seems excessive...
Logged

-->>  This Space 4 Rent  <<--
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #23 on: June 23, 2006, 02:26:42 pm »

As I said before (maybe not here, though), SWIG is just an extra build process.

Here's how this would work if we used Tcl and SWIG:

1. Create the SWIG configuration file.
2. In the Makefile, we add a SWIG processing instruction.
3. SWIG generates additional C files that are compiled.
4. These compiled SWIG files are then added into the binary with the rest of the application.

SWIG just generates code that's compiled--it doesn't actually become anything.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #24 on: June 23, 2006, 06:15:17 pm »

Having SWIG as a build-only dependency is fine, I don't have any issues with that at all. I thought that's what it would do but the descriptions seemed unclear.

Tcl/SWIG is looking like the best option on all counts, but I'm still willing to entertain votes for AngelScript. I can see the dual-dependency side of Tcl/SWIG might put some people off, but how does AngelScript fare against Tcl/SWIG?
Logged

"Cleverly disguised as a responsible adult!"
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #25 on: March 27, 2007, 02:28:02 pm »

I only read the first page, cuz this is a really old thread, but if you're still looking, gaim is an instant messaging client that's written completely in C, and whose plugins are also written in C. They actually implement the idea mentioned earlier of most features being plugins and only absolutely essential IM functions being implemented in the program. Miranda does the same thing, but IMO gaim is easier to use.
Logged
Szandor
Senior Miner
***
Posts: 92



« Reply #26 on: March 27, 2007, 04:53:00 pm »

I only read the first page, cuz this is a really old thread, but if you're still looking, gaim is an instant messaging client that's written completely in C, and whose plugins are also written in C. They actually implement the idea mentioned earlier of most features being plugins and only absolutely essential IM functions being implemented in the program. Miranda does the same thing, but IMO gaim is easier to use.

I've mentioned Miranda around the forum before so I agree. I never use the spell checking or the preject support in CE so I don't want to load them every time I open up the program. I envision EE working like this:

The Core™
The core program includes as few things as possible, providing a simple and minimalist text editor. Think Notepad®, but supporting multiple documents.

The Basics™
With the official Core Application™ we ship a few official Basic Plugins™ that provide the functionality that CE has now, plus some. Turning these plugins off in the preferences would probably speed up the loading time and would be nice for those functions that you never use, but others do.

The Gravy™
The website for EE should include a vast number of third party plugins, provided by our soon-to-be loyal followers and devotees. Savvy coders could then use whatever language we decide to implement to make their own enhancements. Skinning, sounds, RTF-support, alarms, IM-integration, animated monkeys and other stuff would be available here.

The plugin system is, the way I see it, one of the major advantages EE has against the competition. With it (and support for my SDD-syntax) I see no reason to ever use another text editor. Hell, an RTF-plugin would even remove a lot of the need for using Word.
Logged

"Cleverly disguised as an original signature..."
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #27 on: March 27, 2007, 06:39:46 pm »

Szandor, you have it in a nutshell. This is exactly how we plan to distribute EE. The subject of a plugin language has been raging for a while and while I can see the benefits of the plugin language being C, I can also see many problems (a la WinAmp's plugins crashing the app) so I'd prefer an embedded language of some kind.

It is also (as far as I am aware) because of this decentralised nature that Soulfish and Derek Parnell have not yet released the finalised structure for how EE will be built.
Logged

"Cleverly disguised as a responsible adult!"
John Yeung
Senior Miner
***
Posts: 85


« Reply #28 on: March 28, 2007, 06:11:03 am »

The subject of a plugin language has been raging for a while and while I can see the benefits of the plugin language being C, I can also see many problems (a la WinAmp's plugins crashing the app) so I'd prefer an embedded language of some kind.

I know it's already been mentioned, but I'm offering my +1 to NOT using C for the plug-in language.  Besides the dangers of C, I think it will simply be a turn-off for most users and intermediate programmers.  Even expert programmers these days tend to actively avoid C and often even C++ in favor of any modern scripting language, even if they have to learn a new one from scratch.  Personally, my feeling is that a good scripting language provides the right combination of power and ease of use at usually acceptable performance.  Those who are more determined or hard-core are welcome to modify the source code itself.

John
Logged
Szandor
Senior Miner
***
Posts: 92



« Reply #29 on: March 28, 2007, 09:15:53 am »

I would recommend using Ruby. I haven't programmed a lot, but it seems to be very simple and powerful.
Logged

"Cleverly disguised as an original signature..."
Pages: 1 [2] 3
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.129 seconds with 19 queries.