I would like remove (or redefine) a component after setup. Is this possible with the reconfigurable model execution?
that is technically possible with reconfigurability. However, as of openmdao 2.2.1 that is not a fully supported feature. You'll need to experiment a bit on your own.
There are some tests that can show you how to get started.
Related
When building the GRPC libraries from sources, for example on Android, I counter the following issues:
I have to remove libgrpc_unsecure and libgrpc++_unsecure in order
for the initialization of GRPC not to get stuck.
I see that there are two libraries: libprotobuf and libprotobuf-lite.
Which is the differences between them(other than the fact that
probably the lite version contains less functions), which one I
should include?
When generating the .so libraries it is generating also the .a
libraries and if I use the .a libraries a function is not found, so I
have to get back to using the .so, but in that case should I also use
the .a? If not, is there a way to build just the .so?
Is there a link where it specifies the purpose of each library and what should be used? For example I don't think grpc++_reflection is of some use in my case, but how do I know what it contains without having to pass through every symbol in it? I need to better understand how to use the library files.
Yes, libgrpc and libgrpc_unsecure are mutually exclusive. So you need to choose one as a dependency of your application.
Your interpretation is correct. lite version has less feature so you can try lite first and switch to the regular one if it doesn't fit. You may want to check this https://github.com/protocolbuffers/protobuf/blob/main/src/file_lists.cmake to see what's available and what isn't in the lite.
It depends on how you built gRPC.
gRPC has a couple of libraries but grpc++ is the one you want to link against. I don't think it has a comprehensive doc for what is for what so checking out https://github.com/grpc/grpc/blob/master/CMakeLists.txt is the best thing you can do to understand what features those libraries provide.
I am trying to make changes to the behavior of a function and print the results to a file. The ViewCfg plug-in described in the Plug-in Development Guide does something similar, but I am trying to avoid having to use Ast.get, which ViewCfg uses. I am thinking of extending Printer.extensible_printer which, according to the Frama-C API Documentation, is something I can do if I want to obtain a custom pretty-printer.
However, if I extend the pretty-printer as described in the API docs, unless I'm doing something wrong, I notice that the changes I make take place regardless of which project is set as the current project. I'm using File.create_project_from_visitor to create a new project and Project.set_current to set the new project as the current project before I use the custom pretty-printer.
Is it true that any change made by a class that extends Printer.extensible_printer applies to all projects? I happen to be using frama-c-Aluminium-20160502, which I know is not the latest version.
EDIT: Sorry, I should have made this clearer in the beginning, but I'm not actually making changes to the behavior of a function. I'm reading in the behavior of a function, then based on that, I'm trying to generate as output valid C code that's meant to be read as input by another program.
Regarding AST.get, the only reason I was avoiding it was that it sounds like it gets the entire AST, while I'm only interested in part of it, i.e. behaviors. But if I'm just making things harder for myself by avoiding it, then I'll go ahead and use it.
It seems that Xunit no longer supports extending TraitAttributes. They have sealed the class.
There are also some other issues with Autofixture's plugin for AutoData() where we can inject random created data through an attribute. There are a few work around's for this, however I am attempting to evaluate this for a larger product overall. I liked the demo's since they could do small things like SQL, Excel, custom Attributes for category.
It seems there was more functionality before the changes. I have looked at the site and still see some of the features are returning and there isn't much information.
Is there a new set of functionality coming out? Or possibly a change that will allow us to recreate the older functionality in a new way? It seems the SQL and Excel have a work around, however I can't find any information about when the latest version will be compatible with "Autofixture with xUnit.net data theories" Nuget package. I really like what I have seen, though I can say I don't like breaking changes when I look at enterprise solutions. I cringe a little when I think about if I had this in place in an enterprise and I had made a lot of custom attributes, or used Moq and Autofixture to populate and now all my tests were broken. So I guess the other question is, does Xunit seem to change a lot with breaking changes? There is the other option of moving Xunit back a version. Though at some point I would need to know if these things would be fixed or if they were permanently removed, since I wouldn't want to spend time using functionality that is being removed.
Another is AutoFixtureMoqAutoDataAttribute that doesn't load without that side Nuget package. With the side nuget packages not being updated.
I guess the end question may be.. Does anyone know of any plans to get these features to work with the current version of xunit so that I can start implementing and then expect to do mass replaces later? Or are these permanently breaking changes where we shouldn't implement anything that is currently missing.
Thank you in advance.
Short answer
If you want to use xUnit.net 1.x with AutoFixture, use AutoFixture.Xunit.
If you want to use xUnit.net 2.x with AutoFixture, use AutoFixture.Xunit2.
Explanation
xUnit.net 2.0 introduced breaking changes, compared to xUnit.net 1.x (e.g. 1.9.2). For AutoFixture, we wanted to make sure that AutoFixture supports both. There are people who want to upgrade to xUnit.net 2.x as soon as possible, but there are also people who, for various reasons, will need to stay with xUnit.net 1.x for a while longer.
For the people who wanted or needed to stay with xUnit.net 1.x for the time being, we wanted to make sure that they'd still get all the benefits of various bug fixes and new features for the AutoFixture core, so we're maintaining two parallel (but feature complete) Glue Libraries for AutoFixture and xUnit.net.
As an example, we've just released AutoFixture 3.30.3, which addresses a defect in AutoFixture itself. This bug fix thus becomes available for both xUnit.net 1.x and 2.x users.
Thus, when you need to migrate from xUnit.net 1.x to xUnit.net 2.x, you should uninstall AutoFixture.Xunit and instead install AutoFixture.Xunit2. As far as I know, there should be feature parity between the two.
Traits
AutoFixture.Xunit and AutoFixture.Xunit2 don't use the [Trait] attribute, so I don't know exactly what you have in mind regarding this.
AutoMoq
Again, when it comes to AutoFixture.AutoMoq, it doesn't depend on xUnit.net, so I don't understand the question here as well. It sounds like a separate concern, so you may want to consider asking a separate question.
I want a setting to depend on settings of a dynamic list of other projects (well, executed at SBT setting start up, but dynamic in the sense that it is not hard-coded).
I have Def.dynTask to produce a task with a dynamic dependency on other tasks.
Is there a similar way to do this for settings, i.e. produce a setting with a dynamic dependency on other settings?
Or perhaps I misunderstand settings. FYI, my understanding is that settings are computed once at start up; tasks are computed whenever they are requested.
Setting is actually initialized only one per sbt session. The good explanation about that can be found here
If I got your idea in right way, you can do that with TaskKeys and the sbt.Extracted.append method. Be careful, I have faced strange think like this
Could you please help me with two questions regarding organizing tests and using Allure's "feature" tags?
If I have a few different tests but I need all of them to be included into one feature, do I have to write #Features("My Feature") annotation above each test method? Is there a way to write the #Features("My Feature") annotation once and include all required tests in it?
If I have a few logically separated classes with my #Test methods, is there an easy way to call all required tests from one TestSuite class in order to simply manage test queue?
You can write annotation #Feature once per class. But are you really need such feature? Maybe you should think a bit more and split your tests using some other way?
Allrue is not a test framework, it just a report tool. Allure does not run tests. To answer this part of question I need to know more about test framework you use, your environment (Ant, Maven, Jenkins, Teamcity etc)