I starting to look into porting my application from Gtkmm 3.24 to Gtkmm 4.x (not sure which version yet). For now, I am only trying to understand what exactly is deprecated and how much work is needed for planning. One way to ease porting is to look into all deprecated usages in the Gtkmm 3.24 version and update them to the newer flavor before porting. I have found several macros that can help with that:
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
When I #define these, the compiler throws error when meeting deprecated stuff because they have been disabled. This is nice, once the code is leveled up, to make sure the code stays free of deprecated usages.
In my case, however, the code is still full of deprecations and the compiler stops compilation on the first deprecation it meets. This does not help me much in understanding where the deprecations lie and how much work is needed. I could go about and solve every error, one by one, until there is no more (this is ultimately what I will do) but I can't know ahead how much time this will take.
What I would really like are macros that throw warnings when meeting deprecation, but let the compiler go on about building. This way I could get a list of everything that is deprecated in my codebase and plan work appropriately. I have browsed the Gtkmm documentation and codebase but found nothing.
Do such macros exist and if so, what are they?
The solution was to use
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
like I did but to use the -k flag with make. From man make:
-k, --keep-going
Continue as much as possible after an error. While the target
that failed, and those that depend on it, cannot be remade, the
other dependencies of these targets can be processed all the same.
Source: Inkscape GTK+ 3 migration wiki page.
Related
Using the GNOME Documentation, I wanted to write a demo of using webkit and GTK4 together in Vala by porting GTK3 code. However, when changing the library from gtk3 to gtk4, a crazy amount of errors occur, 2726 in total. Most of them are very similar, seeming like library conflicts, saying "error: `Gdk' already contains a definition for ...". It seems like Webkit2GTK is on version 4 in Vala, while in Rust there is a Version 5. It also seems like they had an Experimental flag to support GTK4, but you have to compile from source, and that was almost a year ago.
webkit2gtk is a library that integrates WebKit into GTK: webkit2gtk4 integrates with GTK3; webkit2gtk5 will work with GTK4. It isn't ready yet however, so that's why it's an experimental flag still at this point. Once webkit2gtk5 is out, you'll also have to wait until the Vala bindings are out.
In other words, the library/bindings you're using can't work with GTK4, as that's not what it's built for. That's why you have all those errors.
While I'm making an Android app, Eclipse will strike out some things. More specifically, Gallery. Here is a screen shot:
When I hover my mouse over the warnings, it says The type Gallery is deprecated. I don't know what Deprecated means, but I do know that it's a Java term. Any help would be appreciated. Thanks!
(From the question before editing: The term is deprecated, not depreciated. It's a common typo, but worth being aware of for searching purposes :)
It's basically a bit like "obsolete" - you're encouraged not to use classes or methods which are deprecated. Typically the documentation will explain why you're not meant to use them, and give you a better alternative. The deprecated version is only present for backward compatibility, usually.
It's worth taking this seriously - a lot of the time if you're using a deprecated API, you're coming at something from a fundamentally flawed approach. Date is the clearest example of this, where the Java 1.0 API was almost entirely deprecated in 1.1, when Calendar was introduced. Using the deprecated methods in Date is a sure way of storing up problems for yourself.
See the Oracle "How and when to deprecate APIs" page for more information.
Deprecated means it used to support older SDK, but not anymore. Thats why you get the warning.
It is just a warning most of the times it works, but you most be careful because it could cause problem with newer versions.
Deprecated isn't a Java term. It is used in many other things but a lot in programming. It simply means that it is no longer supported...normally replaced with something else. The Android Docs will help you adapt it to what you need depending on what you're doing
I would like to generate LLVM IR for a toy language whose compiler is written in Scala.
SLEM seems to be exactly what I need but I can't figure out if it's usable in its current
state. I tried to download the sources but I am unable to compile it.
Anyone used it successfully or knows whether it's usable?
I haven't used SLEM, but checking its commits it seems that the last one was from early 2011, so it's updated to LLVM version 2.9 at the latest. The IR has significantly changed since then, so it would probably not be usable if you try to use it with a newer LLVM.
You can update it, of course, but perhaps a better option would be LLVM-J - Java bindings to LLVM. It's updated to LLVM 3.1, in which the IR is far closer to what it is right now, plus it's basically just a wrapper around LLVM's C API, so updating it yourself should be relatively simple.
There is a relatively-new lightweight JVM called Avian that can produce executables for iOS targets.
There isn't too much documentation on the website (and not much can be found searching with Google). I was wondering if anybody was aware of a step-by-step tutorial on how to get a basic Scala program running on iOS, using Avian.
Another alternative JVM to iOS compiler is RoboVM. Although it is at an early stage, it looks quite promising, with examples on how to compile Scala for iOS.
EDIT This was an old answer, valid at that time, but, as #JamesMoore points out, RoboVM is no more. What looks very promising now, and may well be the way to run Scala code in iOS in the near future is Scala Native
Compiled Scala sources are completely standard class files. You should be able to follow the instructions (look for “Embedding”) on the website without large changes, just treat scala-library.jar as a dependency of your code.
I managed to bootstrap the complete compiler and the standard library running on Avian a few days ago.
Some parts might still be a bit rough around the edges, e. g. there is one mandatory fix which will be part of the next release of Scala (2.10.1) but is not in 2.10.0. If you want to play with it right now, you need to use a nightly build until 2.10.1 is released.
If you encounter any additional issues, please report them!
I may not need it anymore, now that Oracle is making JavaFX open-source on iOS and Android!
EDIT: Oracle updated the article to announce that they will not release a JVM, so it looks like JavaFX+Avian may be the way to go.
Running Java byte code on iOS (not-rooted) is not only running that or those JVM. As far as I understand iOS memory management doesn't allow executable memory pages to be writable in user mode. That basically prohibits any JIT compilation.
So even if it's possible to run some compiled (either from Java or Scala) classes on specific Java VM I would carefully check how this VM supports Ahead-Of-Time compilation in order to be runnable on iOS.
As I have seen Avian AOT works well on a desktop. For iOS you will have to check it yourself, although the project looks promising in AOT area.
Semantic issue: 'mutable' cannot be applied to references
The above is only the latest in a series of errors I've received attempting to get the fuego-iphone project to compile. I'm not certain, but it could be related to the way I compiled boost. The project's README recommends using these instructions for compiling boost into a framework, but I had already done so with the more recent instructions here. Could this CLANG error be related to a boost version somehow?
I admit relative ignorance when it comes to C++.
If anyone has any brilliant suggestions for using the fuego library in general with xcode, I have tried quite a few different things, and am pretty much at wit's end. Thanks!
EDIT: Apologies for any ambiguity here, but I'm not asking about mutable references, so much as showing the latest symptom of this issue. The fuego mailing list has a relevant question about using boost 1.48, and checking now, it's clear that I've compiled 1.49, so I'll recompile an earlier version of boost and see if that fixes it somehow.
The mutable modifier means that a field can be changed from within a const method. But for reference fields, that doesn't make any sense, because references can never be changed in C++.