search

GregoryLand / Lorei

Lorei
MIT License
3 stars 0 forks source link

Create a generic API interface #9

Closed GregoryLand closed 10 years ago

GregoryLand commented 10 years ago

Abstract some of the api stuff so we won't have to rewrite the script processors just to add new functions.

SkySom commented 10 years ago

Is there anything else we would need besides for the ApiProvider interface and the ApiDictionary? I'm going to close this. Reopen if there's something else that needs added.

GregoryLand commented 10 years ago

I have a way to get around the casting requirement in scripting i just need a bit more more time to code it up. Why create the Dictionary class instead of just passing around the Dictionary datastructure itself?

SkySom commented 10 years ago

... It was late at night... I think at the time I was thinking ahead a bit and I wanted to get a bit better error checking around the key grabbing. At least that's what I think.

SkySom commented 10 years ago

I mean right now, there's a bit of nulls being thrown around...It's not the safest.

GregoryLand commented 10 years ago

Ok. My current plan for decoupling the apis from the script procs is to turn ApiProvide into something similar to Iunknown from com. It will require a list of methods the api wishes to expose to the script engines. Polymorphism will get the correct list of methods to publish out to the scripts

GregoryLand commented 10 years ago

Pushed a new branch. Checkout the scriptProcessors. Take a look at how the methods are being exposed to the scripting languages

@SkySom

SkySom commented 10 years ago

Oh. Never had thought of implementing IDictionary... Guess that's what happens when you are newer to a Language. All the ScriptProcessors fight over stuff. Lua will grab stuff from AllPrograms, and back and forth.

GregoryLand commented 10 years ago

If you are ok with the changes merge them into master.

I tried to extend Dictionary and it didn't work. So i did some goggling and found out that I was supposed to do the IDictionary thing which was a pain and looks hideous but does the logging you wanted it to. If we need to add more logging or change the logging output we can just open that file do the changes and close it quickly. I will try to forget about its existence. Gahh not being able to just extend that class is nasty.

The script processors do fight. But this isn't exactly a bad thing in my opinion. to be flexible things should be able to grab events from other scripts. there should be a way to check if the program is already controlled by another process from scripting and if so to back off. I think when we revisit the grammar system things will get better.

The coupling problem has gotten a lot better. We are able to swap out large parts of the program with almost no changes to the code base. New script languages can be added easily (cough cough IronRuby cough if one is so inclined)(maybe C# if i feel brave). New things for the scripts todo can be added. Python can do damn near anything. Only a few items are holding us back that are holdovers from my near ancient code base.

The grammar system needs a total rethinking. Each script should be able to setup its own grammar. Each script should also be able to suspend all other grammar evaluation and take singular control over the speech recognizer. I would also like to tweak the python engine to take arbitrary entrypoints. This way we can use it todo setup scripts.

After all that is done we should finally address that error handling problem. Right now a bad script will crash the program. What needs to happen is a rollback of the changes the script made and then nice clean error messages about what went wrong. I consider this low priority right now. It is a lot of work and not really a great benefit at this stage in the game. If a script is broken it isn't to big a deal right now. In a week or two when we are finally getting down to writing python scripts and the next round of google interviews are over I may feel differently on this subject.

On Sun, Jan 5, 2014 at 10:17 PM, Skylar Sommers notifications@github.comwrote:

Oh. Never had thought of implementing IDictionary... Guess that's what happens when you are newer to a Language. All the ScriptProcessors fight over stuff. Lua will grab stuff from AllPrograms, and back and forth.

— Reply to this email directly or view it on GitHubhttps://github.com/GregoryLand/Lorei/issues/9#issuecomment-31624965 .

SkySom commented 10 years ago

Yes... Error handling has been on my list for quite a bit.It's been a beast that has been staring me in the face since the day I added the first exception when the file wasn't found. I do think doing the individual grammar may be a performance issue on program start up, but a blocking Grammar System shouldn't be too hard. The problem with the ScriptProcessor controlling this or that and telling others to back off, is that I fear it may become a race condition. Which ScriptProcessor gets a hold first. Also roll back of scripts? Why would we roll back a script? Maybe kill the script and remove from runtime, but a roll back, I'm not sure what would be changed that would need a roll back.

GregoryLand commented 10 years ago

Currently if a script were to crapout and we ignore the exception it would leave those records in the grammars. Not really a big deal now but once we are setting up grammars for each module or script this should be trivial to cleanup nicely. I agree with the race condition problem but I think we need to start looking at scripts in a modules fashion. A merging of the two systems we have for controlling processes currently into a cohesive system. If we move AllProgramProcs into a python script. Have that python script check the directories for Lua scripts and ignore programs that have Lua scripts this will solve our race condition.

SkySom commented 10 years ago

OH. Ok... Well that may be a bit solved by creating grammars per scripts. It would be one function. Rather 5 or more per script. Since each would have it's own grammar. if it craps out and pass the exception back to Lorei, Lorei can just removed the GrammarBuilder as a whole.

GregoryLand commented 10 years ago

Edited last comment. And exactly what i was thinking with the Grammars.

SkySom commented 10 years ago

The main problem with AllPrograms is that was what was supposed to happen... Lua was supposed to register after it (I don't think we set it up that way actually) and grab things from AllPrograms. AllPrograms was thought up as a catch all. A pool that the others could take from. That still doesn't really stop Python vs Lua fighting, in some cases.

GregoryLand commented 10 years ago

Right and that is why i think we need to start thinking in modules. We build a package of scripts that are designed to work with eachother. It won't matter if they are Lua or python for the most part as long as they are consistent. We redo AllPrograms as a python script. Have that script make sure it isn't humping any lua scripts and call it good for now. Then we can move onto the more interesting stuff.

What really should happen is the whole process management stack should be ripped out and redone in python. The lua interpreter should be rehosted inside of python and the lua scripts evaluated there. This is not something I wish to attempt right now. It can't be done till after the grammar fix.