I want to create a scheduler inheriting cScheduler. Can someone please tell me which are the functions to be written which must override the functions of cscheduler? Currently, I have written the constructor, destructor, startRun, endRun, guessNextEvent, takeNextEvent, putBackEvent. I have also mentioned the class in the initialization file and able to successfully build my project but when I run the simulation I get the error: Class TraCIConnection" not found -- perhaps it's code was not linked in, or the class wasn't registered with Register_Class(), or in the case of modules and channels with Define_Module()/Define_Channel().
The mentioned error has absolutely nothing to do with the custom scheduler you are trying to implement. Omnet complains because you are using the TraCIConnection simple module in the simulation while its C++ code is not linked into the simulation. You may need to add the C++ code to the project or link with an external model that provides that.
Related
I have some plugin's which are basically input and output type definitions. I have a generic controller which i can add to the mvc pipeline. All works fine.
but I'm having trouble setting the api version on this generic controller. I know you can set this based upon an attribute on top of the controller class. But since you can't have this dynamic (attribute) don't allow it, i have no way to set the version for each instance of the generic controller.
Currently i just compile the controller for each instance on runtime and register i using the roslyn compiler.
is there a way to set the api-version somewhere in the pipeline of registering controllers in the mvc pipeline and endup with different api versions endpoints.
This can be achieved by using the Conventions API. It was designed to support this exact type of scenario:
https://github.com/microsoft/aspnet-api-versioning/wiki/API-Version-Conventions
This will only work on closed-generics, but it shouldn't be too much work to make that happen. Here's a couple of basic examples:
// typed, closed generic
options.Conventions.Controller<GenericController<PlugIn1>>().HasApiVersion(1,0);
// untyped, closed generic
var controllerType = typeof(GenericController<>).MakeGenericType(new []{typeof(PlugIn1)});
options.Conventions.Controller(controllerType).HasApiVersion(1,0);
You can also author your own custom conventions a la IControllerConvention. This approach could be used to version all controllers that inherit from GenericController<>. Then you just need to add it to the conventions like this:
options.Conventions.Add(new PlugInControllerConvention());
Hopefully that's enough to get you started. Feel free to ask more questions.
I'm using the SwiftAutomation framework to drive a scriptable app that searches for lyrics and returns a AS record. Everything was working correctly, until...
I mapped the AppleScript record to a custom Swift structure according to the SwiftAutomation documentation. The code in the xxxGlue.swift file looks correct, but the compiler complains about SwiftAutomation.SelfUnpacking, with several follow-on errors, when building the MacOSGlues framework.
public struct LFBLyricsInfoRecord: SwiftAutomation.SelfPacking, SwiftAutomation.SelfUnpacking { ... }
--> .../MacOSGlues/LyricsFBAGlue.swift:700:81: No type named 'SelfUnpacking' in module 'SwiftAutomation'
The SelfPacking public protocol is defined in SwiftAutomation, and SelfUnpacking protocol is defined right under it, but without the public keyword. Is that the cause of the compiler error, and if so, how do I fix it?
OK, I finally found a resolution. Seems you have to use different options for the aeglue utility when generating the glue file for the MacOSGlues framework and for the swift file where you actually use your automation, such as in the test project. In my case, where my scriptable app is named LyricsFBA.app, these were:
aeglue -S LyricsFBA.app
for MacOSGlues (generates a LyricsFBAGlue.swift that references SwiftAutomation, but does not include the custom record structure definition), and
aeglue -D -s 'LyricsInfo:lyricsInfo=score:Int+title:String+artist:String+composer:String+link:String+lyrics:String' LyricsFBA.app
for the test program (generatea a LyricsFBAGlue.swift that does not reference SwiftAutomation, but does include the custom record structure definition).
I'm am trying to run a debug() method but I get the following error when I try to compile the code
Call to a possibly undefined method debug. debug("...");
I assume all I need to do is add an import ... where ... has the debug method defined. However I have tried looking for it and cannot find it.
I can't find what file to import. This is a large project that I got handed down to me to implement small features. I can add debug("msg") into some files with issue but others give me the error msg aboe.
I can't see trace("...") in the debug log.
Since there is no debug function this was obviously a custom function someone wrote. Nobody here can tell you where to find the file to import, you'll need to get more information from whoever you inherited the files from.
Another option is to just comment out the debug calls since based on the name they probably aren't doing anything but giving debugging information which most likely isn't required for the end goal of the program.
I would like to be able to build functionality for my application in a plugin style system for a couple reasons:
New projects can choose which plugins are necessary and not have code for functionality that's not needed
Other developers can build plugins for the system without needing too much knowledge of the core workings.
I'm not really sure how to go about implementing this. I would like to have a plugins folder to host these separately but I guess my questions are:
How do plugins interact with the core system?
How does the folder structure work? Would each hold the standard MVC structure: controllers, services, models, views, etc?
I guess if anyone has a tutorial or some documentation relating to this technique that would be helpful. I've done a bit of searching but it's all a little too closely related to the actual code they're working with instead of the concept and I hadn't found anything specifically related to nodejs.
I suggest an approach similar to what I've done on the uptime project (https://github.com/fzaninotto/uptime/blob/master/app.js#L46):
trigger application events in critical parts of your application
add a 'plugins' section in the applicaition configuration
each plugin name must be a package name. The plugin packages should return either a callback, or an object with an init() function.
either way, inject to the plugins the objects they will need to run (configuration, connections, etc) when calling init(), or executing the callback.
plugin modules register listeners to the application events and modify it
Benefits:
lightweight
rely on npm for dependencies
don't reivent the wheel
Create a plugin prototype for the base
functionality, and let the user define its plugin in a module. In the
module the user would inherit an object from the prototype, extend its
functionality, and then export a constructor which returns the plugin
object.
The main system loads all plugins by require("pluginname") and for
each calls the constructor.
The global VB6 error handler product referred to in the following link claims to "install a small callback hook into the VBE6 debugger":
http://www.everythingaccess.com/simplyvba/globalerrorhandler/howitworks.htm
I would like to implement this product myself because I would like more control over what it is doing. How is the above product likely to be achieving what it does?
The product you are looking at is a COM component. From the documentation that is available on the web site, it sounds like the COM component implements particular component classes. The first thing to do, if you already have the product, would be to fire up SysInternals procmon, run regsvr32 on the DLL, and figure out what component classes are implemented from the registry entries that are created. Once you know this, MSDN may be able to tell you what interfaces correspond to those component classes.
Microsoft developed a framework called Active Scripting that allows you to host a script engine and inject debugging capabilities. If one assumes that VB6 produces an exe that ties into that framework, you might be able to do:
Create a COM component that implements IApplicationDebugger
Implement IApplicationDebugger::onHandleBreakPoint to be able to respond to errors in the VB code
Read MSDN KB Q222966 to find out how to call back to VB from onHandleBreakPoint
It looks like the product injects the ErrEx class using IActiveScript::AddNamedItem. To provide the same behaviour, Implement IActiveScriptSite::GetItemInfo on the same COM component to return a pointer to an instance of (and the associated TypeInfo for) a COM component that implements the same interface as ErrEx. In your implementation of ErrEx.EnableGlobalErrorHandler you would do the following:
CoCreateInstance inproc Process Debug Manager
Cast reference to IRemoteDebugApplication
Register an instance of your IApplicationDebugger component using IRemoteDebugApplication::ConnectDebugger
I glossed over calling IActiveScript::AddNamedItem because I have no idea how you get a pointer to IActiveScript from a running process. Also, I don't know if creating a new instance of the Process Debug Manager will work, or if you somehow have to hook into an existing instance.
I apologize for the confusing explanation, missing information, and glossing over large parts of the process, but this is going waaay back...
You will want to read the Active Scripting APIs article at MSDN.