Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: IDE

From: karim::elfounas::easybraine::com at: 15-Jun-2006 22:46

Hello everybody. This discussion interests me a lot because I also thought a lot about a REBOL IDE. I even worked a bit on an analysis document about that but written in French. I'll try to explain the big picture here. I apologies for my poor English. First, when talking about IDE, I'm not talking about an editor. An IDE contains many more functionalities as compiling, projects management, GUI interface building... I think that creating a Rebol IDE is not copying other IDE. Each language has his style of coding that implies a type of IDE. The good questions are "What do we need when programming REBOL?" and "How to obtain that?". I think a REBOL IDE written in REBOL is an excellent advertising. 1) GENERAL CONCEPT: modular application Of course, an IDE is an environement homogeneous that contains development tools. Let's call them "modules". The more basic idea is a kind of menu or an icon bar (as MS Office97 ugly bar) that launch specific modules (editor, execution, encap,...). Each module of the editor is independent and optional. It allows: * The core IDE is simply a glue between modules and the user. * Any developer can build his own module and maybe propose it to the community. I can even sell it. * Easy evolution of the IDE. 2) LET'S GO DEEPER: not just a module launcher Accessing a functionality with a single click is powerful but is a quite limited. Example, the "Debugging" tools could be launch in many ways : * Simply execute the current script * Execute the script and stop to the first breakpoint * Execute next line * ... Notice that actions are done on specific objects and may needs specific parameters: execute this file; search a word in files of this directory... * Each module must have a list of possible action. * An action may need some parameters (filename of the current script,...) This has an implication: the module must declare to the core IDE the available actions, their parameters and on which king of objects they apply. Practically, the IDE must propose only the possible action. If no script selected, no needs to edit something. 3) What exactly is a module ? All these modules can be written in Rebol but it's convenient to access other things than rebol scripts. If your favourite editor is Emacs, you need a button (or a menu item or...) that launch Emacs with the current filename as parameter. Otherwise, sometimes it's useful to write directly his own new action. By example a button to delete a specific log file. As developer, I want to just clic on "Add new action" and write in a small form the action name "Erase the log" and the corresponding rebol code ( delete %/c/temp/error.log) I think there are 3 main kind of modules : * simple rebol code (typically one liners) * module written in Rebol * external software 4) What kind of objects can be manipulated by the IDE ? Usually, the first use of the IDE is manipulating code which is stored in files (ie rebol scripts). But it can be other kinds of text files (xml, makedoc,...) and even binary files (images, sounds,...) All these files are linked together because they are all parts of the same project. The IDE help USER to manipulate FILES of a PROJECT. The project can be simply a list of files but it can also be a hierarchy of files or directories corresponding to physical directory on hard drive. But it's convenient to order them in a mode logical hierarchy sometimes completely different than directories on disk. The user must be able to add or remove files form the project. I suppose that the IDE must contain a project browser or at least a file browser. It can be obvious but I think it's important to make the difference with a simple text editor. With an IDE, I manage a project, not simply files. We can already visualize the IDE : An icon bar + a file/directory browser. When a click on a file, only some icons are showed as active (other are greyed) 5) How a module works ? A module can be a simple rebol script but structured in a specific way and that must contains specifics things. The IDE, analyse it and display the icons corresponding to actions of the module. These actions can be rebol functions. OK but... when I click on an icon, is the module action executed in the same Rebol session? That's important because if the script is executed by the same rebol process: * The IDE freeze during action execution * If the module crash, all the IDE crash also. I don't think about usual rebol exception but about memory overflow or infinite loop,... It seems more interesting to launch the module in another rebol session if it's not a very simple thing. OK. It implies that a module can be split in two parts. * An interface sub-module, integrated into IDE at runtime. * An execution sub-module, executed into another Rebol process This is not so simple because sometimes we want avoid simultaneous multiple executions of an action ("encap" a script). More complicated, the module has to send informations to IDE. Example : I'm writing code inside the "Code editor" module and I want specific help about a rebol keyword. I just select it and click on rebol dictionary button which is another module. The "Editor" doesn't know about other modules. It just know the IDE. You understand that the process is more complicated: * The "Dictionnary" module asks to IDE for a keyword * The IDE asks to "Editor" module for the current selected word. Practically the modules must be able to communicate and the IDE has to transmit messages. It implies a bidirectional communication between IDE and a module It implies a communication protocol. With the lack of direct interprocess communication with Rebol, I think network protocol is maybe the best solution. Maybe, LNS (aka rebol/services) and/or beer protocol are good solutions. I don't know. I already think about tons of modules : Text editor, debugger, rebol dictionary, anamonitor, multi file search/replace engine, versioning, CVS sync, RAMBO search, makedoc, image transformations, vector graphics editor wich generate draw dialect scripts, rebol.org search engine, database browser,... Some remarks: * I spoke about modules but it doesn't mean Rebol 3.0 modules as discussed on Rebol 3.0 Front Line. Maybe this technology is useful for an IDE. * What I described is not Rebol Desktop (viewtop) but the interface and world-wide-reb file syntax can be a good starting point. * I hope that this message will be useful and I still apologies for my bad English -- Karim EL FOUNAS EasyBraine SA Campagne des Rites, 8 - 1421 Ophain Bois-Seigneur-Isaac Tél : +32 2 387 32 34 Mobile : +32 495 57 32 34 Email : karim.elfounas-easybraine.com