I just installed Xcode 5.1 and found that it definitely requires projects to use ARC. I get
error: garbage collection is no longer supported
when trying to compile Core Plot (version 1.4). Out of curiosity I told Xcode to convert Core Plot to ARC. But it fails with
ARC forbids Objective-C objects in struct
in file CPTPlatformSpecificFunctions.m. I don't want to dive into Core Plot and break something by trying to fix this or similar errors. Is there a compiler setting I have overlooked? Or will there be a Core Plot version which uses ARC soon?
Thanks,
Dirk
Xcode 5.1 doesn't require projects to use ARC, it just finally drops support for garbage collection. Core Plot was never a strictly garbage-collected framework, but it did support building for garbage collection.
You can click on the "Not Now" option when presented with that dialog on opening the Core Plot project, then go to the project build settings. Blank out or remove the GCC_ENABLE_OBJC_GC setting under the user settings at the bottom of the project and the project will build just fine as a manually reference counted target. That's perfectly usable within an ARC or non-ARC application.
If you import the static library you can use core plot in ARC projects. I'm doing so in my ARC app now. Here is a link to the instructions on how to do this:
http://code.google.com/p/core-plot/wiki/UsingCorePlotInApplications
All you need is the library "...core-plot-master/build/Debug-iphoneos/" is where I found it. And then import the headers which can be found in the "....core-plot-master/framework/source" folder. Then follow the directions.
Hope that helps!
Related
I've installed Java 8 and Spring STS on Mac. Running jjs from the command line works. However, when trying to create a new class in a Maven project in STS, the editor doesn't recognise the javafx.* package automatically.
Attached you'll find an example of an image showing that the only Label object suggested is the java.awt one.
Any idea on how I could solve this?
Regards,
M.
I think this is related to the settings of your project. If your project is created with an execution environment JavaSE-1.8, this execution environment doesn't have the javafx API defined as accessible and you would need to manually allow that. If you choose the 1.8 JRE (as a JRE, not an execution environment) in your project settings, the JavaFX API is accessible and works nicely in content-assist, quick fix, etc. This is at least the case if you create a standard Java project.
I can get MvvmCross working with a Windows 8.0 Store App.
I can get SQLite working with a different Windows 8.0 Store App.
I cannot figure out how to get MvvmCross + SQLite working on a Store app.
I always get this Exception:
Failed to construct and initialize ViewModel for type Flux.Core.ViewModels.TestViewModel from locator MvxDefaultViewModelLocator - check MvxTrace for more information
I've spent the entire day searching with google, hoping to solve this myself. The KittenDb example is about as close as I've come, but there's no Store app example in there. (I got the Kitten example working no problem on Android.)
Is there any working example out there?
Thanks!
SQLite for Windows Store is a C++ component and comes in separate ARM, x86 and x64 binaries.
To install it, you need to add a Visual Studio extension - instructions in http://blogs.msdn.com/b/robertgreen/archive/2012/11/13/using-sqlite-in-windows-store-apps.aspx - and then reference that extension from your UI project.
To then link the correct platform version of the Cirrious.MvvmCross.Plugins.Sqlite.WindowsStore.dll assembly to your UI project, you further need to adapt your .csproj file with a <Choose> block a bit like the one in https://nuget.codeplex.com/discussions/446656
There is an open issue within MvvmCross to make SQLite easier to use from nuget (see https://github.com/MvvmCross/MvvmCross/issues/307) but I don't know if anyone is actively working on addressing this issue currently - currently users seem to be just putting up with challenges of different processor architectures and following the manual steps to adapt their projects.
Recently we moved to QT 5.0.2 from QT4.8. Our project now needs more DLL files than the earlier. It requires qml, opengl, printer modules. However we did not use any of these modules in our application. The size of exe file increased due to additional DLLs.
QT-= qml opengl -> did not exclude this module from our application.
Are these additional DLLs are compulsory for Qt 5.0.2 ? Is there any way to come out from this? We need to exclude these dlls to reduce exe size.
Some of the modules you use may be dependent on those you don't, which means your project depends on them indirectly. For example, by default, some modules (QtWebKit, QtMultimedia) utilize ANGLE which uses OpenGL. You can try to trace those dependencies by using a program named Dependency Walker (available here). The Qt GUI has changed a lot since 4.8, and there are now separate modules for printing and other functions (see here).
Sources:
Qt 5 on Windows ANGLE and OpenGL
Qt 5 Deployment on Windows
By the way, someone has (had) a similar problem: http://www.qtcentre.org/archive/index.php/t-52102.html. (Unfortunately, there is no solution in that link.)
It turned out that this is actually a bug in Qt.
In Qt Location API page at Nokia website, the link to SDK's download requires login by using my existing account on their web site but keeps saying "Singing in..." and never returns. Anybody has an idea? Has Nokia / Degia shutdown the project?
Update) I'm intending desktop app for a large scale opensource framework in robotics. I'll start from Ubuntu but should support multiple desktop OSs.
Qt Location was going to be a full add-on module for Qt 5.0, but it was cut and reworked instead. As of Qt 5.5, Qt Location is listed as a Technology Preview, which suggests it will be a standard module soon.
Here's a couple quotes about why it was cut and how it was reworked:
Unfortunately, some modules either lost their maintainers, or their
quality was not up to scratch, so they were excluded from the Qt 5.0.0
release. Qt Location did not make the cut, and its code base still
requires lots of cleaning up.
The plan is to include those modules when they are ready though.
-
A lot of the components in Qt Location have been converted to value
types. Previously components such as Coordinate, GeoCircle,
GeoRectangle etc were QObjects. Now they are value types which
provides a much nicer API.
By the way, Nokia is no longer involved in the development of Qt. I would not recommend downloading an old SDK from Nokia. You can get the most recent release from http://qt.io/download
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.