Sign in to follow this  
gilad_novik

AS IDE - Beta

Recommended Posts

gilad_novik    122
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]

Share this post


Link to post
Share on other sites
Deyja    920
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.

Share this post


Link to post
Share on other sites
kunitoki    100
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 ?


Share this post


Link to post
Share on other sites
gilad_novik    122
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.

Share this post


Link to post
Share on other sites
Deyja    920
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. :)

Share this post


Link to post
Share on other sites
Deyja    920
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.

Share this post


Link to post
Share on other sites
gilad_novik    122
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.


class asNewEngine : public asIScriptEngine
{
public:
void SomeNewFunction() {}
...
};

asIScriptEngine* asCreateScriptEngine(asDWORD version)
{
return new asNewEngine;
}




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.

Share this post


Link to post
Share on other sites
Dentoid    122
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

Share this post


Link to post
Share on other sites
gilad_novik    122
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.

Share this post


Link to post
Share on other sites
Rain Dog    136
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.

Share this post


Link to post
Share on other sites
gilad_novik    122
Here are my updates:

I now have a working dll to be used as an IDE. Since AS interface is still changing, and I didn't want to limit the debugger to a specific version of AS, I decided not to use AS inside the code, but rather to use a callback mechanism.

When creating the debugger, you need to pass it an interface that wrap the actual calls.

class asDebugCallback
{
public:
virtual bool Compile(const char*)=0;
virtual int Execute()=0;
virtual void Abort()=0;
virtual void Suspend()=0;
};

Inside your actual code, you need to implement that interface, and call the actual functions by yourself (using the context interface). That way, you can use a different version of the script engine even with an older version of the debugger.

When creating the engine, you supply your interface.

class asDebugApplication
{
public:
virtual bool Start()=0;
virtual void Stop()=0;

virtual void Show()=0;
virtual void Hide()=0;
};

asDebugApplication* pApp=asDebugCreateApplication((asDebugCallback*)pMyCallback);
assert(pApp);
pApp->Show();
pApp->Start();

That's the general idea. I'm still testing it (for now there are no problems), and I'll upload it soon when it's ready for release.

If you have any comment about the way it works, please post them here.

Gilad

Share this post


Link to post
Share on other sites
gilad_novik    122
Here is the first release: http://gilad.gsetup.com/ASDebug.zip

Some notes:

In order to make it easier to bind to AS, there is a file called "ASDebugContext.h" which calls the actual context from AS. Check "MainDlg.h" to see how to implement it in your code ("MainDlg.h" is just the file from my test application. Don't try to compile it, it's there for reference only).

There are some notes inside "ASDebug.h", please verify it's clear enough for you.

I'll add some more functions to the interface soon, so you'll be able to customize the debug window.

Please note that currently the window is running in its own thread. Since I need to handle idle messages and translating of accelerator commands, I've decided to put everything in a seperate thread so you won't have to do it yourself in your code.

Since I'm terrible writing documents (and english is not my strong language), I'll be glad for any help writing some documents so I can create a webpage for the debugger.

Some technical notes: Everything was written using ATL/WTL. There are no known dependencies. Editor is based on Scintilla control.

Gilad

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this