I am compiling some Vala code on ElementaryOS Loki, which ships with GTK Version 3.18. Now I get (a lot of) deprecated warnings like:
src/ScreenGrabber.vala:64.55-64.94: warning: Gdk.Display.get_device_manager has been deprecated since 3.20.
src/ScreenGrabber.vala:64.55-64.115: warning: Gdk.DeviceManager.get_client_pointer has been deprecated since 3.20
src/ScreenGrabber.vala:85.19-85.50: warning: Gdk.Screen.get_active_window has been deprecated since 3.22
But the recommended alternative methods that should be used in favor of the "deprecated" ones simply dont't exist in 3.18 yet, so I cannot use them.
How can I make valac giving me correct warnings for the given GTK Version? I tend to switch off warnings completely which I would rather like to avoid, if possible. valac has a switch --target-glib, but there is no equivalent "--target-gtk"
--
EDIT:
e.g. this little program demonstrates the problem if compiled with valac -o test test.vala --pkg=gtk+-3.0 (on ElementaryOS Loki, with GTK 3.18)
using Gtk;
public class Test {
public Test() {
var manager = Gdk.Display.get_default().get_device_manager();
}
public static int main(string[] args) {
var test = new Test();
return 0;
}
}
Probably the best solution is to use the --enable-deprecated switch when compiling with valac. You could also try --disable-since-check if that doesn't work. The --disable-since-check was introduced in Vala 0.32 with the new [Version] attribute.
In an ideal world a library would also distribute its binding for Vala. This would mean the binding is kept in sync with the library. See Vala Bindings Upstream guide.
Both GTK+ and Vala are GNOME hosted projects. Although Vala carries the GTK+ bindings, both projects are kept in sync and should work well together. Specifically relating to your question, GTK+ 3.18 was released 22 September 2015 and Vala 0.30 on the 18 September 2015. Both of these were in time for the GNOME 3.18 release on 23 September 2015.
What has happened with Loki is, according to the Loki beta release blog post, GTK+3.18 and Vala 0.32 have been bundled together. Vala 0.32 carries bindings for GTK+3.20.
So you could download the gtk+-3.0.vapi and gdk-3.0.vapi from the Vala 0.30.0 release and use that instead. This, unfortunately, will show a lot of different warnings because of the way version information is noted in VAPIs has recently changed. Vala now uses [Version] instead of [Deprecated]. These different warnings can be suppressed with --enable-deprecated.
If you contribute to a distribution then there is no fundamental reason why distributions need to bundle the Vala compiler with the bindings that come with the compiler. So they could have two, or more, packages. One for the compiler, one for the non-upstreamed bindings, e.g. vala-0.30 and vala-non-upstreamed-bindings-0.30. Although that is a bit of a simplification, for example Vala will continue to carry a binding some time after it has been generated upstream.
Related
Are #babel/runtime and #babel/plugin-transform-runtime supposed to be on the same version (e.g. both 7.2.0 exactly)? Or can I (as a library author) specify #babel/runtime dependency as ^7.0.0, whilst having the latest #babel/plugin-transform-runtime?
I'm aware that during the beta versions of Babel 7, there was a breaking change in beta.56 (see https://stackoverflow.com/a/51686837/2148762), but I'm guessing this should no longer be the case with the current stable version?
The reason I ask this is I'd ideally want the helpers from #babel/runtime to be shared across different packages, and to me leaving the version range open seems like a good idea. But at the same time, I'm not sure how low I should go (^7.0.0 or ^7.2.0), and whether there's an implicit contract between #babel/runtime and #babel/plugin-transform-runtime with regards to version numbers.
By default, #babel/plugin-transform-runtime is only allowed to output references to #babel/runtime that work on ^7.0.0 because it does not know what version you'd otherwise want to use, and doing anything else would cause lots of issues for users. This means that what you want to do is safe. The downside of this is that, if we add new helpers moving forward, your code would not be able to take advantage of the #babel/runtime version of them (because you might still be using a #babel/runtime version that doesn't have them.
Users can specify the version in the arguments for the transform, if you want to specifically make use of helpers that may have been added to Babel since 7.0.0, e.g.
{
"plugins": [
["#babel/plugin-transform-runtime", { version: "^7.2.0" }],
]
}
would then require you to have "#babel/runtime": "^7.2.0" in your package.json.
For instance, since support for the newer decorators proposal didn't land until Babel 7.1.5, if you use transform-runtime and non-legacy decorators, the decorators helper will still be inserted into every file where you use decorators, instead of importing it from #babel/runtime. To get the shared helper, you need to specify version: "^7.1.5" in your options for transform-runtime.
Can I (as a library author) specify #babel/runtime dependency as ^7.0.0, whilst having the latest #babel/plugin-transform-runtime?
Yes, this is safe.
I'm guessing this should no longer be the case with the current stable version?
Correct, that issue was because people failed to take the beta versioning into account.
The plugin description for a libpeas plugin contains a line determining the Loader and with this the programming language the plugin is written in. It seems the documentation includes not list of available languages. Inspecting the git repository of the project, a top-level directory "Loaders" can be found listing entries for
c,
gjs,
seed and
python.
It is unclear also if the python version expected is 2 or 3.
These are by far fewer languages that the related gobject introspection provides support for.
Are the listed 4 all available loaders? Or do external projects exist that provides more loaders?
AFAIK yes, those are all the loaders which are available, though it would make much more sense to ask on an official libpeas forum (like the mailing list or IRC channel) than on SO.
Vala uses the C loader, and can be used with libpeas.
Also, a lot of the projects listed on that site aren't in particularly good shape. For example, JGIR is probably in better shape than most (IIRC there is a GSoC student working on it right now), but it can't handle out or inout parameters. A libpeas loader isn't really necessary until the language is actually usable with GI.
For people that would needs a list of supported loaders, i think this may be useful.
As stated on the valadoc page for libpeas-1.0/Peas.Engine.enable_loader ¹ :
C : The C plugin loader is always enabled ;
lua5.1 : Lua 5.1 loader - Example ;
python : Python2 loader ;
python3 : Python3 loader - Example.
gjs : GJS loader - EDIT: Seems to have been disconstinued.
I suppose that using the C loader may works for Genie plugins too.
I've seen several conflicting descriptions of how to do this around the google results, and haven't been able to get any of them to work.
My problem is basically this: where I call ExecutionEngine::getPointerToFunction (with an llvm::Function*), I'd like to instead get the pretty-printed x86 assembly that would be produced for this function.
Anybody?
[ETA: I'm using LLVM 3.3. The descriptions I've found seem to be for earlier versions of LLVM.]
It turns out that you can add an event listener to a JIT ExecutionEngine with ExecutionEngine::RegisterJITEventListener. If you provide an instance of that class, you can have your callback invoked when machine code is generated for you, and you'll be given a pointer to the machine code and its length. With this, you can call llvm::sys::disassembleBuffer to get a description of the machine code buffer.
However, the llvm::sys::disassembleBuffer function just defers to the udis library if LLVM was compiled with that support. Since my build of LLVM didn't have this flag set and I can't rebuild it, I'll just look into using the udis library directly:
https://github.com/vmt/udis86
I am using this software called Simple Agent Pro, and it primarily uses TCL code. I was wondering anybody familiar with TCL or Sapro would be kind enough to tell me how to import the modules into the .tel file for Sapro.
When I try this:
package require tclOO.h
The program stops working.
Any help would be appreciated.
I don't know Simple Agent Pro at all, but if you're doing a “guerilla install” of TclOO then you need a few things:
Make sure you're using Tcl 8.5 (see what package require Tcl returns).
If you're using 8.4 (note: 8.4 EOLed this month), TclOO will not work at all (and it cannot be backported).
If you're using 8.6, it already provides the TclOO package and you shouldn't need to fuss around with all this.
Do a build of TclOO and install it to a location you prefer.
This will require Tcl's internal source files; TclOO explicitly pokes its nose into places where most code shouldn't.
You probably don't need to have a custom build of 8.5; just the configured sources somewhere will do. (You might need to hack the configure scripts a little bit.)
Add the location that you installed TclOO to to the search path inside your Tcl 8.5 program.
lappend auto_path /the_dir/you_put/it_in
If you're using Windows, it's probably easiest to use forward slashes for this path anyway (this is a directory name that is always highly protected before it hits the OS, so that's OK).
Now you should be able to require/use the package.
package require TclOO
oo::class create Foo {
# etc.
}
Note that the case and exactly how you write it matters. The version you get ought to be at least 1.0 (earlier versions were for development only) which corresponds exactly with the API as supported in Tcl 8.6 (modulo a few things that require 8.6 for other reasons, such as being able to yield inside a method which only works in 8.6 because that's where yield was first defined).
You probably mean
package require TclOO
Case and other stuff is important there.
Next time you should also include the stack trace. If the program stops working, it should display that either as dialog or on stdout.
I have an Eclipse plugin and I am aiming for 3.1 or 3.2 as a minimum version to support. The problem is that some of my code only works in version 3.5 and above (see my other question: Is there an alternative to CaretListener in Eclipse?).
Now that I have code that works in the older versions and different code that works in the newer versions, is there a way that I can call the newer code only if my plugin is running in version 3.5 or above and then revert to the old code if running anything older?
As a test, I've created two plugins that have the same class within it (just doing slightly different things). I have marked the org.eclipse.ui dependency as a minimum of 3.5 in one plugin and 3.1 as a minimum in the other but I can't get the one that relies on 3.5 to be ignored in older versions...
Can anyone help?
Thanks,
Alan
You could use org.eclipse.core.runtime.Platform to get the org.eclipse.ui Bundle and check the version.
Version ui = Platform.getBundle("org.eclipse.ui").getVersion();
// then do something with that
Register MyListener if >=3.5, and OldMyListener otherwise.
EDIT:
Right, the above is only good for capturing differences in runtime behaviour.
Eclipse supports a couple of tricks for only loading some classes.
The easiest from a development point of view is the trick that #ShiDoiSi mentioned.
Bundle myBundle = org.osgi.framework.FrameworkUtil.getBundle(this.class);
Version ui = Platform.getBundle("org.eclipse.ui").getVersion();
Version cutOff = new Version(3,5,0);
final Executable processListener;
if (ui.compareTo(cutOff)<0) {
Class pc = myBundle.loadClass("my.pkg.OldListenerProcess");
processListener = (Executable) pc.newInstance();
} else {
Class pc = myBundle.loadClass("my.pkg.ListenerProcess");
processListener = (Executable) pc.newInstance();
}
processListener.execute(targetObject);
Another option that uses more of the eclipse framework would be defining your own extension point so that contributions from other bundles can decide which version to use. Basically it's the same pattern as above, except the version checking is done by the dependency ranges on the plugin the contributes the Executable to run. Depend on org.eclipse.ui [0.0.0,3.5.0) for the old way, and simply specifying org.eclipse.ui 3.5.0 (that's an open ended range on 3.5.0) for the current way. Then you can read your extension and instantiate the class provided.
If you were creating extra plugins for this (a little heavy weight for the 2 differences) you could define a command in your main plugin, and have the extra plugins provide the equivalent handler. The plugins would still have to have dependency ranges so that only one would load for the <3.5 or >=3.5 case. Then using the command API you could execute the command (and the correct handler would run).
ICommandService cmdS
= (ICommandService) workbenchWindow.getService(ICommandService.class);
Command process = cmdS.getCommand("my.pkg.ListenerProcess");
ParameterizedCommand cmd = new ParameterizedCommand(process, null);
IHandlerService handlerS
= (IHandlerService) workbenchWindow.getService(IHandlerService.class);
IEvaluationContext ctx = handlerS.createContextSnapshot(false);
ctx.addVariable("toAddListener", targetObject);
handlerS.executeCommandInContext(cmd, null, ctx);
Then your implementation of handler would use HandlerUtil.getVariable(event, "toAddListener") to extract the object you need from the ExecutionEvent.
It sounds to me that you should be supplying two plugins, one supporting version 3.1 to "just below" 3.5, and the other one from 3.5 upwards. So you don't really get to choose, it's basically the Eclipse plugin layer choosing the right one based on your version ranges.
Or if you provide just the compiled class files, then of course you could load the required class dynamically based on testing the version of the running Eclipse.