I've uploaded my first release of the IDE for your comments. Currently there are no built in functions and classes, but you can load it from an external file. Debugger is working as well. Please note that this is a first beta release, so I'm looking forward for your comments. IMPORTANT NOTE: Inside the package you'll find "readme.txt". PLEASE READ IT FIRST!!! It should explain shortly how to use the debugger. IDE is available here: http://gilad.gsetup.com/ASIDE.zip Gilad [Edited by - gilad_novik on May 18, 2006 1:36:53 AM]

gilad: interesting !

Deyja: with my ide your preprocessor thingie is already plugged into, so you don't have to deal with this. actually i'm thinking about the interface for the dll since i have a basic one and don't cover all the cases i'm facing.
i just would like to collect informations about users what kind of callbacks they would need when they plug into new types and such. if you provide me of some of your use case i can understand well what plugged callbacks we need.
actually, i've thought about this callbacks (cause i've exposed GUI objects to the script engine, and they need more than just registering types):

<needed_plugin_types>
you should expose to the engine (before registering new types) which kind of other types your classes uses, and in which plugin they resides. this is made mainly for let a library rely on types declared on another one, so i can have a string_plugin.dll, and in myown_plugin.dll still use the "String" type declared in the other library. we can sure avoid this and rely only to an error in the engine, anyway this idea i'm thinking about.

<register_plugin>
when the plugin library is loaded, and the needed_plugin_types check succedeed, here you register your types and functions

<pre_compilation_step>
when i recompile a script, i use this for doing cleanup of a previously launched session that may have allocated c++ objects still living in the application memory (when dealing with c++ gui objects that may persists over a single function execution, avoiding angelscript reference count is needed).

are any other pluggable callbacks needed ?

Deyja: You can register your stuff using a plugin (use the LOAD command as described in the readme.txt file), or you can build a new version of AS dll and put the new dll inside the same folder. Just make sure you don't change anything in the interface itself.

If you do want to change stuff, you can create your own interface (inherited from the original engine), and cast when needed. That way, the engine would still be able to work using the original interface.

Originally I wanted to use tabbed interface, but I've decided to go with single view (it's only a script and not a full programming language). If other users would want it as well, I might add support for it later.

Intellisense: I might use AS original parser to support intellisense. I still need to think how to implement it.

Yeah, I meant you can inherit your own engine from asIScriptEngine and implement whatever you want in there. The reason I want to work on the base engine is that I don't want every user to compile his own IDE. I want a single IDE with an option to load new stuff dynamically. Eventually, I'll make the IDE open source (when I'll be satisfied with my code), so you'll be able to add new features. But again, I prefer the IDE to work with the basic engine interface. That's the exact reason I didn't supplied built-in classes with it - I want a user to have total control of his stuff.

In order to create your own engine, create a new class from asIScriptEngine, and modify asCreateScriptEngine to create your new engine.



That's the reason I've used AS as an external DLL and not static linking. I wanted to allow people to change the engine when needed without recompiling the IDE.

I haven't actually tried ASIDE out, so I hope I'm not stating something stupid now, but...

If you've got an AS debugger, it might be a nice idea to have some way of attaching it to a separate process that's using AngelScript for embedded debugging. I'm not sure how really (I guess it would need some interface code in the host app, but that's ok by me). Just so that you could set breakpoints and trace game scripts and stuff.

Just my $0.02 :)

/Anders

Actually yeah. I had a thought recently, and I think I'll convert ASIDE into a DLL rather than a stand alone app. That way, you can embed it into your own application easily, and tie it into your own script engine.

I agree. Some type of easier to use debugger might be highly useful, something that might say, return a char* of the current stack, ability to add, remove break points, set conditional breakpoints, etc, might be highly useful.