I am interested in multiobjective optimization using genetic algorithm or particle swam. For this I understood, that I need to install the pyopt plugin.
Though it seems that the driver listed here:
https://github.com/OpenMDAO-Plugins?page=1
are not suitable for the latest release. Is this right?
Is there another repository for the current drivers?
I am also not sure how to install the drivers as the 'plugin' command is not in my path and I did not find it when I dowloaded the git repository.
Could you point me to an multiobjective nsga tutorial?
In addition to this I am interested in the dakota-plugin in.
The plugins page you've referenced is for an Older version of OpenMDAO (V 0.0.13 and older). For 1.7.x, we handle plugins a bit differently. OpenMDAO is now a standard python package and any plugins can just list it as a dependency.
That being said, you don't actually need a plugin for pyopt_sparse. The wrapper for it is built into OpenMDAO. You just need to install pyopt_sparse from it's bitbucket repo. After that you can just use it.
You can see an example of setting up pyopt_sparse in the OpenMDAO tests suite here.
Related
I'm currently starting with JFrog Artifactory. Up to now I have only been working with source code control systems not with binary repositories.
Can someone please tell how the versioning of files is done in Artifactory?
I have been trying to deploy a file, then change it and deploy it again.
The checksum has changed, so it's the new file. But it seems that the old version is gone.
So it looks like there are no version of files. If I want that do I have to do it in the filename?
I found versions related to packages.
But I was thinking to use it for other files as well.
Thanks for your help
Christoph
Artifactory, unlike a VCS system, is not managing a history of versions for a given path. When you deploy an artifacts over an existing artifact, it will overwrite it (you can block this by configuring the right permissions).
If you wish to manage permission for generic artifacts (ones which are not managed by a known package manager like npm, Maven etc.), there are a couple of options you can take:
Add the version as part of the artifact name, for example foo-1.0.0.zip
Add the version as part of the artifact path, for example /foo/1.0.0/foo.zip
Combine the 2 above approaches, for example /foo/1.0.0/foo-1.0.0.zip
Use an existing package management tool which is flexible enough to handle generic packages. Many people are using Maven to manage all types of packages beyond Java ones (it comes with its pros and cons)
From the Artifactory point of view there are a couple of capabilities you can leverage:
Generic repositories - aimed at managing proprietary packages which are not managed by a known package manager
Custom repository layout - can be used to define a custom layout for your generic repository and assist with tasks like automatic snapshot version cleanup
Properties - can be used to add version (and other) metadata to your artifacts which can used for searching, querying,resolution and more
Lastly, Conan is another option you should consider. Conan is a package manager intended for C and C++ packages. It is natively supported in Artifactory and can give you a more complete solution for managing your C libraries.
I just accidentally refactored QList to QSet, and Qt faithfully did it, to all of its own sources too... (yup, that was dumb!)
Thankfully my code is source controlled, I just reverted everything, would it be feasible/sensible to make a git repo for the Qt sources too? (I have the free version so I didn't think I could modify them anyway...?)
Is there a hidden setting that will prevent its sources from being modifiable, to stop me from doing this again?
I'm currently using the maintenance tool to install a newer version of Qt, but other than update or add/remove, there wasn't a re-install option that I could see, am I missing something?
There's no point to using source code control for an install: it's not source code. It's artifacts. You already know how to protect artifacts of all sorts from modification. Proper filesystem attributes will do it just fine.
Your finished Qt installation should not be writable by you. It would be by default on Unix systems when installed using a privileged package manager. Elsewhere: you need to make it read only. If you build from source, then recursively making the install folder read-only as the last step after installation is all it takes; and since you should be already automating your Qt build, then adding the "make read-only" step is trivial.
Thankfully my code is source controlled, I just reverted everything, would it be feasible/sensible to make a git repo for the Qt sources too? (I have the free version so I didn't think I could modify them anyway...?)
Feasible? Definitely. Sensible? Perhaps, assuming that by "make a git repo" you mean "cloning the official Qt repos from Git". It depends on how many times you plan on making the same renaming mistake. :D But seriously, I think there are benefits to building Qt yourself:
You can easily debug and check the implementation of API that you're using.
You can configure Qt to skip building stuff that you're not interested in.
You can easily patch Qt if there's a bug that you know of a fix for but hasn't been merged into Qt itself yet.
There are downsides too, though. You might run into build issues if you're using configure flags that the CI doesn't use (such as a -no-foo option). It can take a while to build depending on how many submodules you have and what kind of machine you're building on.
In general, if you're not using API that's in dev and not yet released, it's probably not worth bothering.
If you're still interested, this page has instructions for building Qt from Git:
https://wiki.qt.io/Building_Qt_5_from_Git
Is there a hidden setting that will prevent its sources from being modifiable, to stop me from doing this again?
Couldn't you set some permissions on the source directory? I've never had to do this, but have been bitten by it on unrelated occasions before, so I know it works. :D
I'm currently using the maintenance tool to install a newer version of Qt, but other than update or add/remove, there wasn't a re-install option that I could see, am I missing something?
Remove and add is your only option, I think. Otherwise, you can always keep a backup of the source by just copying the whole directory.
Is there any tutorial for the scripted plugin? Or maybe a new way to test plugins. I've found a tutorial that seems to be a bit old.
If I have to resort to Scripted, some questions that come to my mind:
Do I need to publish local my plugin before running scripted?
Can I refer to the version located in version.sbt from my tests?
For the record, I'm also using the cross-build plugin, so if possible, the tests would need to cover both 0.12 and 0.13 versions.
(Author of the linked testing sbt plugins here) There hasn't been major changes to scripted since I first wrote it, but I updated some of the details.
To test the plugin end-to-end, publishing locally I think makes sense.
See the updated post. You can pass version number as a property using scriptedLaunchOpts, and catch it with System.getProperty on the other side.
Eugene's answer is still relevant, but now, Sbt Plugins Testing has a proper documentation page in the official sbt documnetation site:
http://www.scala-sbt.org/release/docs/Testing-sbt-plugins.html
I am looking for tips on how to package my Qt-based application for Ubuntu/Debian distributions. Let's say the application (executable) is myapp. Running objdump -p myapp | grep NEEDED, I see that it has the following dependencies:
libicuuc.so.44
libicui18n.so.44
libicudata.so.44
libQtGui.so.4
libQtCore.so.4
libpthread.so.0
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
I have gone through several online documents (listed at the end of this question), but am still fuzzy on where to install the actual files.
The Debian Filesystem Hierarchy Standard would suggest (I think) installing myapp in /usr/local/bin but I'm not sure about the ICU and Qt libs. It's important that the exact version of some of these libraries are used. (They have draft APIs which are being utilized that might break in future versions.)
I want to avoid "shared library hell" so that would incline me to place them in the application directory (/usr/local/bin), but the Debian Filesystem Heirarchy Standard would seem to discourage that.
I could place them in /usr/local/lib/myapp but then how do I ensure the correct version is linked dynamically? And if I do this, what do I have to do to add this directory to LD_LIBRARY_PATH on the target system?
As you can tell, I'm quite new to packaging for Ubuntu systems, so the direction I'm going may be completely wrong. I'm interesting in hearing from others who are doing this as to what they have found works best, particularly from a stability and ease-of-maintenance perspective.
Here are some of the docs I have gone through thus far:
Ubuntu Packaging Guide
Create Ubuntu deb-package from a Qt-application
Debian Filesystem Hierarchy Standard
Debian Policy Manual (on system)
Debian Developer's Reference (on system)
Debian New Maintainers' Guide (on system)
You need to look at the control section. You should not be distributing those shared libraries unless you are building them from source in your code. Those libraries belong to other packages that you need to list as Depends or Build-Depends for your package.
You say you are new to packaging on Ubuntu systems, what platforms have you packaged for? If it was only Windows, you are used to dll hell. It is much easier to avoid on Linux since you can say it requires certain libraries to be installed and the package installer knows how to find those libraries.
If you really want to make sure that your application uses the libraries that you ship it with, it probably makes sense to just do static linking of the license allows it. Since you are using a special, specific version of the libraries, you don't really want any other applications to use your libraries instead of the system libs supplied by the package management system. I've built static version of Qt before, and it's somewhat inconvenient, but not enormously moreso than building the usual dynamically linked version of Qt. I haven't worked with ICU, but I imagine it's no worse.
Failing that... Yeah, stuff it all in the application's directory, neatly away from the rest of the system. In my experience, most apps that do that sort of thing don't follow any official distribution standards for doing so, so users don't have very specific expectations in that regard.
I've been reading about drupal install profiles, and I'm wondering if there's much of a difference between using a packaged install profile vs. installing core + manually installing the modules listed in the install profiles?
I'd like to do the latter (manually installing each) to control the versions of each module installed, which I can't control with a packaged install profile that may not have been maintained.
But should I or will I be opening the door to something I'm not aware of? Shouldn't the 2 be identical, just one automated and other is manual?
What kiamlaluno said, plus the fact that installation profiles may perform custom configuration of settings on install, might construct custom views/content-types/etc (especially by means of features.module, which you can see heavy use of in OpenAtrium), and might provide other custom code in distro-specific module.
The short answer is, no you can't just replicate an install profile by downloading a clean drupal with all those modules -- best bet is to use the install profile. If you're worried about module versions, just make sure you're using a profile that's actively maintained.
The difference is that an installation profile includes the right version of all the modules it needs.
This means that differently from manually installing each module, you don't need to verify the correct version of the module X that effectively works together the module Y; there are few cases where one module doesn't work well when version A of another module is installed, and you need to install version B of the same module, if you don't want problems.
An installation profile can have a custom installation page that allows you to change some parameters of your site; it also allows the installation profile author to define a patch that needs to be applied a module, in order to fix a bug of the module, or to make it work better with another module.
If you need to set a site to work for a particular purpose, installation profiles are useful for you as they allow you to set the site correctly without to know all the details about how a Drupal site needs to be set.
I believe you can specify the versions of the modules you want to install see