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.
Related
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.
So I am converting a project from Unity 4.x to 5.x and there are a number of functions that the Unity compiler is warning me that are no longer supported or are obsolete.
My question is do these functions still work? (even though they are marked as obsolete)
I know at some point they need to be updated to the newer API but for the moment I just need to fix the bugs so that the game works. Are these functions still usable? or are they potentially the source of runtime bugs?
Thanks
All obsolete functions has been replaced with new functions. So should take a backup and update your project. Go to Assets->Run API Updater, if your project in not getting updated automatically. Dont worry unity will take care of most of the things.
Yes, it's still work ! They just only warning it.
But i suggest you should change for better result, Unity 5 will update you code from old project, then you should change it following warning, just replace
using "xxxx" instead.
to the current context.
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++.
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.