Orange widgets between 2.7 and 3.2 - orange

I'm running Orange 3.2 and 2.7, but both are missing key widgets for my work.
My installation of 2.7 came without the 'Discretize' (although I've had it included before). So I moved on to 3.2, which now appears not to have the 'Regression trees' which I also use.
Anyone else experienced this?
Any tips?
Can I copy widgets from one generation to another?
Thanks,

Orange 2.7 vs Orange 3.2 are based on two different major Python versions (2.7 and 3+) and are thus largely incompatible out-of-the-box. Not all Orange2 widgets appear to have been ported to the new version yet. Discretize missing for you in Orange2, however, appears to be a bug, which you should report on their issue tracker.

How did you install Orange? Which operating system do you use?
If you are on Windows, I would guess that you probably manually installed some libraries (before or after installing Orange) whose versions are incompatible with Orange. In particular, the discretization widget uses Qwt and also Orange's custom extensions of some Qt classes, written in C++. You are probably also missing most visualization widgets.
Os X does not have this problem since Python is included in a bundle.
Can you run Orange from command line with arguments -l 4 --force-discovery and report what it says about the discretization widget?

Related

PlantUML does not render arrows well in a class diagram (Skinparam linetype ortho mode)

I'm trying to make some complex class diagrams with PlantUML by having ortho layout for the relations between the classes.
Some arrows, especially those which are connected at the bottom of an element does not rendered very well.
If it is important, I use VS Code with jebbs.plantuml extension.
Anybody with the same experience?
Problem looks like to be due to an old version of plantuml. The newest released version can be found through the plantuml main page http://plantuml.com/ on http://plantuml.com/download.
The latest available plantuml.jar beta file: http://beta.plantuml.net/plantuml.jar (at http://beta.plantuml.net/ you might also find other files of the latest beta version)
I resolved the problem with installing the latest version of Plantuml.jar as well as latest version (2.38) of Graphviz.
It looks like I used the older one (2.28)
Thank you for the help.

Modelica libraries use different MSL version

I want to use two Modelica libraries together, in Dymola, so for convenience I wrote a little script, loadLibraries.mos that just opens the two libraries.
But they use different versions of the MSL (3.2.1 versus 3.2.2), defined by the uses annotation in the top level package.mo:
annotation(uses(Modelica(version="3.2.1")));
The library developed by us uses 3.2.2, the library that uses MSL 3.2.1 is developed by someone else.
Now whenever I run the mos script (or when I open the two libraries manually), Dymola wants to run an update script. As far as I can see, nothing gets changed by the update script, so I would like to
either not run it at all, e.g. by defining a range of accepted versions like annotation(uses(Modelica(version>="3.2.1")));
or always run it, without asking first, e.g. by setting some flag AlwaysSilentyAcceptMSLUpgrade.
Under Edit, Options, Version there is a checkmark Force upgrade of models to MSL version but I am unsure how to use it from my mos script (for all users).
My pragmatic solution would be to ask yourself if your own library really needs anything from 3.2.2 which is not yet present in 3.2.1. Hence change your library to only require 3.2.1. Or the other way round (given you can change the package.mo of the other library) change the uses annotation there to 3.2.2
Don't change your own library, but make the library using Modelica 3.2.1 read-only (e.g. by making the files read-only).
That should skip the prompt (at least from Dymola 2016) - and as far as I understand you don't edit that library yourself anyway.
That works for libraries that don't need any update between the versions; which obviously holds for Modelica 3.2.1->3.2.2 since there is no conversion - but it would also work if there were a conversion that didn't influence this particular library.

Where can I find gtkmm/overlay.h?

I'm using this page to create an overlay widget but I don't have gtkmm/overlay.h
libgtkmm-3.0-dev (v3.10.1) is installed. I can't seem to find overlay.h in my install or even the latest unstable source (v3.11.10)
Any ideas where I can find this?
The "Since gtkmm 3.2" text in that documentation for Gtk::Overlay is wrong. It was actually added in gtkmm 3.14:
https://git.gnome.org/browse/gtkmm/tree/NEWS
I have corrected it in gtkmm's git, so it will be correct online when we do a release. Sorry about that.
However, GtkOverlay has been in GTK+ since GTK+ 3.2, so you can use that part of the C API from your C++ code, by using gobj() and Glib::wrap():
http://www.gtkmm.org/docs/libgnomedbmm-3.0/docs/tutorial/html/ch03.html#sec-basics-gobj-and-wrap

What's the different between these opencv libs that have the very similar name ? Which should I put into project libraries?

I am on Linux(Ubuntu) with OpenCV 2.4 installed. I am try to use Eclipse to create an opencv project. When I build the project, I got collect2: ld returned 1 exit status error which I guess is caused by missing libs. Then I put libraries in this project, but I find every lib has three very similar brothers, like:
libopencv_highgui.so
libopencv_highgui.so.2.4
libopencv_highgui.so.2.4.0
So, which one should I add to project libraries? And what's the different between them?
Best Regards.
libopencv_highgui.so and libopencv_highgui.so.2.4 are probably symbolic links to libopencv_highgui.so.2.4.0.
Libraries frequently do this so that software that needs to link against specific versions can while keeping the generic library also exposed.
This is mainly useful when a program to be linked against a major or minor version of a library. Consider if a legacy application needed to link against version 1.2 of libopencv_highgui. The program couldn't link against libopencv_highgui.so because that's not guaranteed to be the correct version. However, the program could link against libopencv_highgui.so.1.2. libopencv_highgui.so.1.2 may be a symbolic link to libopencv_highgui.so.1.2.3, but that would be ok since the third number usually means a minor bug fix that won't break compatibility.
So this brings up which file you should link against. This really depends. Unless you need to depend on some bug or quirk of a specific minor revision, I would definitely avoid linking against the 2.4.0 one. That ties your program specifically to version 2.4.0. When 2.4.1 gets released (or trickles down your distro's package manager), it probably won't break your program.
If you link against libopencv_highgui.so and then 2.5 is installed as the main lib (and then libopencv_highgui.so links to libopencv_highgui.so.2.5.0), there is a chance that your program will not link correctly since the second number does sometimes mean compatibility changes.
So in short, if it's a personal project, just link to whatever you want. libopencv_highgui.so is probably safe if it's personal. If it's going to be distributed, figure out what versions of the library your code will link properly against and then use the vaguest one possible. For example, if your code works with 2.2, 2.3 and 2.4, you should go ahead and link to libopencv_highgui.so. If it only works specifically with 2.4.0, you should link with libopencv_highgui.so.2.4.0. If it will work with any sub revision of 2.4, you should go with libopencv_highgui.so.2.4.
Basically you have to make a choice about what you think will link properly on the most people's setups.
I think I make some mistake here. What I need is these libraries, But when I add them into project libraries. YOU SHOULD USE THESE NAMES, for the library I mentioned in the question, we should add opencv_highgui in to eclipse libraries dependency but libopencv_highgui.so.2.4. For the future use, I write these stuff here.

What is the relation between GTK, GTK+ and GTK2?

I'm confused by the GTK terminology. According to Wikipedia, there seem to be bindings to GTK+ that are called GTK (GtkAda) and GTK2 (gtk2hs, Gtk2-Perl).
Could someone clear this up for me?
The first incarnation of the project was called GTK (which stood for GIMP Toolkit).
At some very early point, while the project was still part of The GIMP (and before version 1.0), it was renamed to GTK+. Despite this, people often referred to it as GTK out of convenience or ignorance.
The GTK+ name was used for more than 20 years through versions 1.x, 2.x, and 3.x, but the "GIMP Toolkit" expansion was dropped. I don't know when exactly this happened but perhaps during the 1.x → 2.x transition.
There is nothing officially called GTK2. It's just what some people call the 2.x series of GTK+.
On 2019-02-06, the project was renamed back to GTK, which will affect version 4.0 onwards.
GTK/GTK+ and GTK2 are different versions of the same API. GTK is an old, deprecated version, GTK2 is the previous one, GTK+ 3/GTK3 is the current version.
GTK+ is the correct name of the old API, but most people just call it GTK.
The C++ bindings for GTK+ are part of the project GTKmm.
GTK is the library for creating GUI-s for Linux / GNU. It has several versions (I think the latest is version 3).
In order for other programming languages to use it (other than C), there have to exist libraries that can bind GTK to that particular language.
PHP-GTK means that there's a library binding GTK to PHP enabling PHP to create apps that can be displayed in a nice interface. It supports, however, only up to version 2.2 of the GTK.
Same goes for other languages, they have a prefix / suffix and (GtkAda for example) those libraries also tell you up to what version they support GTK (since you might want to try newer GTK functions that aren't available in the library binding GTK to your language).