> also, the previous version in this branch was broken, i imagine that > someone forgot to commit changes to the cocos.layer.interpreter file > and stuff. > i "fixed" that (did the last i could to get the editor running again) > > i am very concerned of what the change may be. We shouldnt change > stuff that people may be already depending on. > Bruce most likely uses the interpreter. > All our presentations use the interpreter. > Im sure there is more. > > > So, please: > - dont change cocos > - if theres something you want to change about cocos, lets discuss it. > - if theres something new you want to add to cocos, leave it in the > editor dir and we can later add it. > - the last point can be ignored if you know what you are doing. but > pleeease, its better to discuss this stuff than to make our next > release a pain. > > Lucio.
alright. I take the blame. I changed the interpreter to add what I thought were useful enhancements. I thought that since we were working on a branch it wouldn't matter until we merged with mainstream. I understand the implications of my change in regards to maintaining compatibility with mainstream cocos. If it's alright with you guys, I can do the following: 1. revert the interpeter changes, so we keep the default cocos interpreter stuff 2. create a new branch with the new interpreter implementation, and start discussing those changes on that new branch. I'll wait for your opinion on this, before I start (breaking things up again :-)) Just for your information, the enhancements I wanted to make were: - add persisting history (using readline / something else) - add tab completion based - make the interpreter infrastructure flexible enough so that the interpreter can be used disregarding the app-specific context (i.e. there is a default interpreter implementation that can be overriden for a specific app -- like the editor, which adds its custom features) The main idea of the new interpreter is that the interpreter layer (the part responsible for showing the results back on screen) and the interpreter engine (the part responsible for evaluating the commands) are decoupled as much as possible. This would allow to incrementally enhance each part without affecting each other (mostly due to a future goal of eventually being able to embed a full ipython interpreter). The editor console inherits from this default implementation, and adds support for custom 'builtin' variables and commands. ricardo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cocos2d discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cocos-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
