Origen has modes for the top level DUT and IP. However, the mode API doesn't allow the flexibility to define attributes at will. There are pre-defined attributes, some of which (e.g. typ_voltage) look specific to a particular company or device.
In contrast, the Parameters module does allow flexible parameter/attribute definitions to be created within a 'context'. What is really the conceptual difference between a chip 'mode' and a parameter 'context'? They both require the user to set them.
add_mode :mymode do |m|
m.typ_voltage = 1.0.V
# I believe I am limited to what I can define here
end
define_params :mycontext do |params|
params.i.can.put.whatever.i.want = 'bdedkje'
end
They both contain methods with_modes and with_params that look similar in function. Why not make the mode attributes work exactly like the more flexible params API?
thx
Being able to arbitrarily add named attributes to a mode seems like a good idea to me, but you are right that it is not supported today.
No particular reason for that other than nobody has seen a need for it until now, but there would be no problems accepting a PR to add it.
Ideally, when implementing that, it would be good to try and do it via a module which can then be included into other classes to provide the same functionality e.g. to give pins, bits, etc. the same ability.
Related
For logic testing purposes, I am using a clickable button triggering "source.inject()." The preceding logic for the agents is dependent on agent characteristics. Thus, it is preferable to have control over which characteristics they get during initiation when testing the model logic. Searching the AnyLogic documentation on the source block's inject()-function does not show any way to mandate the initial characteristics.
I have tried using "add_patients();" this allows for the creation of agents, and I can specify the characteristics inside the parentheses as I like. However, the agents will not enter the statechart if I use this function.
instead of using a source, use a enter block, then you can control the parameters of your agent. So instead of source.inject() you will do:
Patient patient=add_patients(a,b,c,d);
enter.take(patient);
Or course you will need a population of patients defined somewhere to do that.
If you don't have a population of agents then you can do
Patient patient=new Patient(a,b,c,d);
enter.take(patient);
As you all know, and as the VS-/ C# documentation states as well, there is no relation between the ThreadId's of the CLR on the one hand (ManagedThreadId) and those of the underlying process (ProcessThreadId) on the other hand, therefore no possibility being at hand to use one information in order to get the other.
Nonetheless, the VS-/C# IDE seems to be capable of bringing about exactly that, f. i. in it's ThreadDebugging-Window, where any of the current application's threads with their respective ManagedThreadIds are shown correctly assigned to their process-based counterparts.
Does anyone have an idea which way could be gone to achieve sth. similar programmatically (or an idea of how to get the corresponding information the CLR is hiding from the user)? Reflection offered no way, and up to now I didn't find a P/Invoke / API function being suitable to that end either.
Thanks & many greets
Heinzi
I Use a CQRS thin read layer to provide denormalized lists/reporting data for the UI.
In some parts of my application I want to provide a search box so the user can filter through the data.
Lucene.NET is my full text search engine of choice at the moment, as I've implemented it before and am very happy with it.
But where does the searching side of things fit in with CQRS?
I see two options but there are probably more.
1] My Controller can pass the search string to a search layer (Lucene.NET) which returns a list of ID that I can then pass to the CQRS read layer. The read layer will take these IDs and assemble them into a WHERE ID IN (1,2,3) clause, ultimately returning a DataTable or IEnumerable back to the controller.
List<int> ids = searchLayer.SearchCustomers("searchString");
result = readLayer.GetCustomers(ids);
2] My thin read layer can have searching coded directly into it, so I just call
readLayer.GetListOfCustomers("search string", page, page1);
Remember that using CQRS doesn't mean that you use it in every part of your application. Slicing an application into smaller components allows using various architectural principles and patterns as they make sense. A full text search API might be one of these components.
Without knowing all the details of your application, I would lean towards a single entry point from your controller into your search layer (your option #2 above). I think your controller shouldn't know that it needs to call layer #1 for full-text enabled searching and layer #2 for just regular WHERE clause type searching.
I would assume you would have two different 'contexts' (e.g. SQLContext and LuceneContext), and these would be dependencies injected into your ReadLayer. Your read layer logic should then make the decision on when to use LuceneContext and when to use SQLContext; your controller won't know and shouldn't know.
This also allows you to swap out LuceneContext for MongoContext if there's a compelling reason in the future without your controller knowing or having to change.
And if you use interfaces for everything (e.g. ISearchContext is implemented by LuceneContext and MongoContext), then really the only change for swapping out contexts is in your IoC container's initialization/rules.
So, go with option #2, inject in your dependencies, have your controller just work through your read layer, and you should be good to go. Hopefully this helps!
I have a requirement to add fields onto a form based on data from another set of entities. Is this possible using an event script or does it require a plugin?
Given that I understand your assignment correctly, it can be done using JavaScript as well as a plugin. There is a significant difference that you need to take into consideration.
Is the change to the other entities to be made only when an actual user loads a form? If so, JS is the right way.
Or perhaps you need to ensure that those values are written even if a console client or system process retrieves the value of the primary entity? In that case, C# is your only option.
EDIT:
Simply accessing the values from any entity in the onload event can be done using a call to oData. I believe someone else asked a similar question recently. The basic format will look like this.
http://Server:Port/Organization
/XrmServices/2011/OrganizationData.svc
/TheEntityLogicalNameOfYoursSet()?$filter=FieldName eq 'ValueOfIt'
Some extra remarks.
If you're targeting on-line installation, the syntax will differ, of course, because the Schema-Server-Port-Organization are provided in a different pattern (https, orgName.crm4.something.something.com etc.). You can look it up on Settings.
Perhaps it should go without saying and I'm sure you realize it but for completeness' sake, TheEntityLogicalNameOfYours needs to be substituted for the actual name (unless that is your actual name, in which case I'll be worried, haha).
If you're new to this whole oData thingy, keep asking. I got the impression that the info I'm giving you is appreciated but not really producing "aha!" experience for you. You might want to ask separate questions, though. Some examples right off the top of my head.
a. "How do I perform oData call in JavaScript?"
b. "How do I access the fetched data?"
c. "How do I add/remove/hide a field programmatically on a form?"
d. "How do I combine data from...?"
I need to standardize on how I classify and handle errors/exceptions 'gracefully'.
I currently use a process by which I report the errors to a function passing an error-number, severity-code, location-info and extra-info-string. This function returns boolean true if the error is fatal and the app should die, false otherwise. As part of it's process, apart from visual-feedback to the user, the function also log-to-file errors of above some severity-level.
Error-number indexes an array of strings explaining the type of error, e.g.:'File access','User Input','Thread-creation','Network access', etc. Severity-code is binary OR of 0,1,2 or 4, 0=informative, 1=user_retry, 2=cannot_complete, 4=cannot_continue. Location-info is module & function, and Extra-info is parameter- and local variable values.
I want to make this into a standard way of error-handling that I can put in a library and re-use in all my apps. I mainly use C/C++ on Linux, but would want to use the resultant library with other languages/platforms as well.
An idea is to extend the error-type
array to indicate some default
behavior for a given severity-level,
but should this then become the
action taken and give no options to
the user?
Or: should such extension be a
sub-array of options that the user
need to pick from? The problem with
this is that the options would of
necessity be generalized
programming-related options that may
very-well completely baffle an
end-user.
Or: should each app that uses the
error-lib routine pass along its own
array of either errors or default
behaviors - but this will defeat the
purpose of the library...
Or: should the severity-levels be
handled in each app?
Or: what do you suggest? How do you handle errors? How can I improve this?
How you handle the errors really depends upon the application.A Web application has a different Error-Catching mechanism than A Desktop Application, and both of those differ drastically to an asynchronous messaging system.
That being said the a common practice in error handling is to handle it at the lowest possible level where it can be dealt with. This usually means the Application Layer or the GUI.
I like the severity levels. Perhaps you can have a pluggable Error-collection library with different error output providers and severity level provider.
Output providers could include things like a logginProvider and IgnoreErrorsProvider.
Severity providers would probably be something implemented by each project since severity levels are usually determined by that type of project in which it occurs. (For example, network connection issues are more severe for a banking application than for a contact management system).