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]

I know you probably aren't expecting this sort of request right away, but as you'd expect I use my preprocessor with angelscript. Is there any way now to plug boost::wave or my preprocessor into the build process, or will there be?

It'd also be nice because it gives me the option of not using a DLL to register everything. Since angelscript has classes declared in script now I could create (even auto-generate) a dummy header that declares all the types the script uses instead of having to duplicate all the registration code in a DLL.

Other things...
It'd be nice if you could have multiple documents open and it was tabbed.
Intellisense. :)

I actually use Visual Studio to edit scripts. I give them a .c extension to get it to do syntax hiliting, and use an auto-generated dummy header to enable intellisense. Everything else being equal, yours has a working script debugger. Unfortunatly, not everything else is equal and it would be a lot of work to get your debugger working with my scripts.

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.

kunitoki; I'd appreciate it if you interface with my preprocessor through a DLL. If you set it up, I can maintain it and release new versions. :)

Quote: 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.

I understood that (I did read the readme) though I didn't think of actually replacing the angelscript.dll. I think I'll have to explain exactly why this would be so much work for my projects (and anyone who happens to base their project off of my wrapper library). Programs interface their code with angelscript by making lots of calls into asIScriptEngine at startup. Ultimatly, this can't be changed. The usual process involves the coder adding registration code to a single big list of calls whenever a new type or function needs to be added to the script interface. This can be changed. What I have done is de-centralize this registration. Ultimatly, theres a big list of registration statements that gets executed. Can't help that. But instead of maintaining it themselves, the programmer uses some simple macros that mimic the functions in asIScriptEngine. Instead of having one file that is dependant on the entire project, you can drop registration code right into the implementation .cpp of every class in the project. And that, you see, is the problem. I can't just copy and paste a function. I'd either have to duplicate all that code or, actually, as I've begun to think more about it, I'm starting to see ways I can do it 'automagically', depending on how your dll interface works.

Quote: 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.

If you meant inherit from asIScriptEngine... ew.

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.