BTW where do i get the latest version of the SDK? I could only find the RC2 SDK, but in the Sep 20 recent nightly builds the entry says several things about about plugins changing...
CB_DECLARE_PLUGIN();
1. is there away to register file type classes from the plugin?
2. Is there a standard format for plugin settings and configuration files? Where are they stored? I want to store the list of interpreters, paths, command strings etc.
ConfigManager* cfg = Manager::Get()->GetConfigManager(_T("your_plugin_name"));
cfg->Write(_T("/any/kind/of/path"), some_string);
cfg->Write(_T("/paths/are/not/filesystem/paths"), some_float);
cfg->Write(_T("/paths/are/just/a/way/for/you/to/organize/data"), some_bool);
some_string = cfg->Read(_T("/another/path"), a_default_string_if_the_key_doesnt_exist);
some_int = cfg->ReadInt(_T("/always/start/the/paths/with/a/slash"), a default_int);
...and so on and so forth...
I am sure you aware of PyDev (http://pydev.sourceforge.net/) but perhaps you could port over the Java based python debugger for use in Code::Blocks.
Feedback appreciated.Compiles & runs fine here. Anyway: One annoying thing I have discovered. Once you choose "Run..." from the interpreters menu an OpenFile dialog appears. But if you click "Cancel" in this dialog the plugin complains that the target does not exist and won't let you out of this loop until you really select a file.
Compiles & runs fine here. Anyway: One annoying thing I have discovered. Once you choose "Run..." from the interpreters menu an OpenFile dialog appears. But if you click "Cancel" in this dialog the plugin complains that the target does not exist and won't let you out of this loop until you really select a file.
In addition one time I run C::B again all my interpreters (well, one -Python- for this time ;-)) were lost. I have no clue why, maybe it was my fault.
any suggests on how to reduce DLL bloat? (5mb :shock:)Sure: Remove the compiler option "-DcbDEBUG" and add "-s" (strip symbols) instead. This should help. ;-)
you should have told me that people were actually using the InterpretedLangs plugin. I fixed the bugs weeks ago [...]Well what get's posted here is automatically used - you can count on that. ;-)
I heard rumors that even the major guru liked InterpretedLangs...
... One obvious thing I can add is the option to run the interpreter in a codeblocks dockable window.That's what I exactly need. Hope you have time to do.
I can't build the new version. It gives this error referring to #include <sdk.h>:
InterpretedLangs.h:21: calling fdopen: No such file or directory
It seems Code::Blocks has troubles with the paths. At the project build options -> Directories -> Compiler this line exists;
$(#cb)\sdk
When I select it and press edit -> browse, It finds the sdk directory successfuly. Global variables are also set. I can build Code::Blocks itself successfuly.
Any idea?
I use;
Code::Blocks svn build 3236
...sdk.h.gch: not used because `cbDEBUG' not defined.Yes, that's easy to resolve:
...here comes my very little "update": Fixing the compiling warnings + PCH issues, optimising the project file and fixing the bug with .size()-1.
Please verify that you setup the variables WX_SUFFIX and WX_CFG so that they match your configuration. Note that only the debug release (which is the default one) will use PCH.
With regards, Morten.
As stated before
"Once you choose "Run..." from the interpreters menu an OpenFile dialog appears."
I think if a file is already open within ide, then this file must be processed without asking. Or this type of behaviour can be specified from the settings page.
I think it would make more sense if he got his own project on Berlios or Sourceforge.
Why don't you take python's moto: "Release early release often", nothing wrong with placing alpha quality code in a repository. When the code is in heavy state of flux you will be able to track changes better when using source control.
Personally, I like that it works this way as I don't necessarily want to have to open a file before I run it or run the currently active file.That's ok. Also to keep your personal taste and to add some more usability, what do you think about using $processafile that means process the active file in ide like this:
What I wanted to do was respond to right clicks in the editors tabs and/or editor pane with menu options for the appropriate actions... Will this be acceptable? My other plan is to put the last 10 executed commands directly in the interpreters menu as another shortcut way to execute commonly run scripts. These will be stored persistently...It's nice if right clicks would bring a compact menu gathered within an "InterpretedLang" or something smilar.
2. recent command list on the interpreters menu
3. rerouting console input and output to a dockable window in codeblocks (there will be a few problems implementing this but its not a big deal)That's what I'm eager with.
what do you think about using $processafile that means process the active file in ide like this:
load;$processafile $interpreter $file
Additionaly There are times I have more than one file open. I want to process them all like this:
consult;$processallfiles $interpreter consult('$files').
It's nice if right clicks would bring a compact menu gathered within an "InterpretedLang" or something smilar.
Recent command list on the interpreters menu is also nice
Caused by an incorrect arrangement of #includes and pre-compiled header.
Or an -include sdk.h flag in the project while using pre-compiled headers.
I've just commited Revision 15 of the Interpreted Langs plugins:Hmmmm... whereas all previous versions work properly I have an issue with this one: First I had to point to the Python include/lib folder the first time for compilation which wasn't considered in the project files. It compiled/linked fine but now whenever I start C::B I receive an error, that the python plugin could not be loaded. What am I missing? Do I need to put e.g. the Python DLL somewhere?! What's behind the dependency on Python?!
sorry about the current state of that plugin -- you should just remove py_embedder.cpp, py_embedder.h, libpython and any python related vars from the project [...]Alright... will do that... thanks! :P Sounds interesting what you still have in mind! 8)
BTW: You can use a branch for this experimental stuff thus trunk would always be a "usable" version. SVN can do so much more that "just trunk". ;-)
With regards, Morten.
latest build (rev 31), which includes a file explorer here:I guess it's rev 35 already...?! ;-)
#include <sdk.h>
#include <cbplugin.h> // for "class cbPlugin"
I guess it's rev 35 already...?! ;-)
After these changes I was able to compile... now I'm testing... ;-)
rev 44 win32 buildJust a minor note: For FileExplorer: IsFileWritable() is a wx28 method of wxFileName. This breaks compilation under wx26.