There is Default, YES, NO, but what is the Default value? is YES or NO?
https://xcodebuildsettings.com/#compiler_index_store_enable
tl;dr: it defaults to YES.
Based on empirical observations and logical conclusions (hah), this property always defaults to YES, as of today.
This setting is what enables indexing of features such as autocompletion and rich navigation in Xcode. So when you build the project via Xcode, it will certainly be true, because it will seize the opportunity that the project is already being built to create that indexing for us.
One would expect that this property should default to NO when building via CLI (i.e. xcodebuild command line), however, as reported by Peter Stainberger here, that's not the case:
So yeah, as of today, this always defaults to YES, however, it could be changed in the future.
Related
My question should be very simple to answer for anyone not being a self-taught newbie like me...
On this page is a cheatsheet concerning a function to be used in GIS/DB environnement : http://www.bostongis.com/pgsql2shp_shp2pgsql_quickguide.bqg
I would like to create a script allowing users to just have to click on it to launch the process, given the proper datas. But I don't understand how to use this. It obviously doesn't work in a Python console, nor directly in the windows console. How is it supposed to work ? What language is this ?
Thanks
shp2pgsql is indeed a command line tool. It comes with your PostgreSQL/PostGIS installation (usually) and, if not accessible via PATH-variable, can (usually) be run from within the /bin-folder in your PostgreSQL-Installation. You can also always 'make' the programm from source in any location yourself, if needed.
EDIT:
One way to set up a script (independent of whether you use it within qgis own python environment or not) would be to use Pythons subprocess (or os.system) module (check related question here) to write to shell and execute shp2pgsql.
A slightly more sophisitcated solution to (batch) insert (multiple) shapefiles via script could be to implement ogr2ogr via gdal/ogr module within python (check this blog). That, however, would require a working installation of the gdal core library, and the respective Python bindings (at least to use outside of QGIS Python environment, where it is pre-installed AFAIK), which can be tiresome at times. Once installed correctly, it offers a powerful (I dare say almighty) toolset for geodata management and manipulation via Python, though.
Apart from that, the blog link I provided also states the implementation of a batch insert script/tool (which operates ogr2ogr) in qgis 2.8 toolbox...maybe that can help you, either with your work directly or (via sourcecode) to point you in the direction of creating your own tool.
I built up a module that creates a window with an edit box from windows' EDIT windowclass. It is designed to only work with ansi character set and not using any unicode.
I make use of EM_GETHANDLE to recieve the buffer to the edit control.
Now here is my problem: (quoted from link above)
Note For Comctl32.dll version 6, the buffer always contains an array of WCHARs, regardless of whether an ANSI or Unicode function created the edit control. For more information on DLL versions, see Common Control Versions.
So when my module gets loaded by an application that has comctl32 initialized, my whole code breaks.
My Question: Is there a way to prevent CreateWindowA to use comclt32 or does anyone have an idea to fix this problem?
The application uses COMCTL32.DLL if it is specified in the app's manifest as described e.g. here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb773175%28v=vs.85%29.aspx
If your module is DLL, then you might try use some isolation technique so it does not rely on what version of COMCTL32.DLL the .exe decided to use, but that might bring many other drawbacks.
I recommend to use WM_GETTEXTA or GetWindowTextA() instead, which will copy converted string into your buffer. Designing a module which requires old version of a DLL to work correctly is simply bad idea.
I'm a Java developer and I've downloaded the Eclipse for C (course purposes) and to my amazement the control+space shortcut (for autocomplete) did not work.
I've created a new project and a new class using the wizzards and started to type "print" and then tried to find an autocomplete feature.
After a bit of googling I arrived at C/C++->Editor->Content Assist->Advanced and there I verified that Help proposals,Parsing-based proposals and Template proposals options were checked.
I then went over to the Keys preferences page using the link at that page and entered a binding for all relevant content assist from before C\C++ Content Assist (type...) and chose in the When box the C\C++ Editor option.
But alas no autocompletion was offered.
Can someone please point me to the right direction?
UPDATE: I'm accepting the answer not because I'm sure it's right but because I've realised I've made some mistakes with the configuration of the eclipse and have seen that with another installation/configuration (i.e. a friend of mines) eclipse does auto complete, even if it still lack many of the java version features.
Use the Advanced panel in the Preferences window to configure the behavior of the Content Assist (Ctrl+Space) command. Go to Preferences->C/C++->Editor->Content Assist->Advanced. Check the parsing-based-Proposals in Default Proposal kinds.
Although the eclipse doesn't provide perfect auto-complete, but it works..
This sometimes happens when you have the indexer turned off.
Try to enable the indexer and rebuild the index.
See this question in CDT FAQ. It contains info about how to find indexer error which might prevent auto-complete.
I'm no Eclipse expert (and I don't even play one on TV), but it might be that it only autocompletes function names that are declared in the current scope - have you added #include <stdio.h> to the top of your source file to get the declarations for the standard I/O functions?
You should verify that you have the gcc home (i.e. C:\MinGW-4.4.1\bin) defined in the path environment variable (if you're using windows and if not then it's equivelant). Also verify that the file has a .c suffix and that the indexer is on as yousf said.
I think, not sure, that you need to then run eclipse with the -clean flag and the autocomplete will work.
Ittai
i answered it here:
Eclipse: How to add include path to be used by autocompletion
You have to explicitly tell it where to find the header:
⇒ Right click on your project ⇒ go to 'C/C++ Include Paths and
Symbols' ⇒ select 'Add External Include Path...' ⇒ browse
to the location of your header files ⇒ refresh
Maybe it is related with KeyAssist bindings.
If you have tried with content assist:
Enter into Window > Preferences. Menu "General" -> "Keys"
Inside search for "Template" and set:
Key Binding to -> "Ctrl + Space"
When: "Editing Test"
Image helper Image Menu Key Assist Code Complete
Vim offers this functionality by scanning your #include's (the shortcut is Ctrl-N, or Ctrl-P to search backwards). If you can't find any better solution, one last resort could be looking into eclim, which integrates vim features into Eclipse (or vice-versa), and that's sure to offer this feature.
Whenever I start a new project, I have to go through setting up the debugger with Eclipse time and time again before I can use it. Isn't there a default setting for all new C projects I can change?
I'm not sure exactly what you mean by "setting up the debugger" (perhaps you can clarify), but under "Preferences -> Run/Debug -> Launching -> Default Launchers" you should be able to select your preferred launcher for different kind of launch modes. This can also be selected individually for each launch configuration.
Typically it is up to the toolchain and/or project to determine which debugger/launcher is suitable to use for that specific project, but I know there is a bug in CDT which prevents toolchains from properly specifying the default launcher to use.
I only use Eclipse for Java, so I can't give you an authoritative answer. But since no one else seems to be answering:
Java projects have a (more or less) hidden file in the project directory called .project and another one called .settings . I'm not sure if this would apply to the C environment as well, but it seems likely. You may want to look at the set of such "hidden" files for a well set up project and a virginal project side by side to find out which settings make the difference.
Given that information, you may be able to simply edit (perhaps with some assistance from a script you can write yourself) the file(s) in question to do the configuration textually without a lot of mouse clicking.
What's the best way to determine if the version of the JRE installed on a machine is high enough for the application which the user wants to run? Is there a way of doing it using java-only stuff? I'd like the solution to work on Windows/Linux/MacOSX - if the JRE version is too low a message should be displayed. Currently I'm getting an exception if i try to run it on Java 1.5 (the app is built for Java 1.6). If there's no universal solution, what's the best way to do it on Windows?
You could do this using reflection and two compilers. Compile a main class with the oldest java version you want to be able to run at all with. It checks the version using System.getProperty("java.version"), or whatever, and then uses reflection to load your real main class if that check passes, possibly even loading the jar directly. The JRE shouldn't load any classes that weren't referenced by your outer main class at compile time.
You might consider Java Webstart. Even if the name implies something like applets, it's about standalone-applications. Webstart is a launcher, that checks a JNLP-file (a simple XML-file, where you configure the download-location of your app, the needed Java-version and some other metadata) and starts your app with the correct JRE. It even updates the application, if a newer version is available. The downside is, you have to write a JNLP-file. Here is an example:
<?xml version="1.0" encoding="utf-8"?>
<!--
###############################################################################
#
# #(#)draw.jnlp 1.6 02/09/11
#
# JNLP File for Draw Demo Application
#
###############################################################################
-->
<jnlp spec="0.2 1.0"
codebase="http://java.sun.com/javase/technologies/desktop/javawebstart/apps"
href="draw.jnlp">
<information>
<title>Draw 4 App</title>
<vendor>Sun Microsystems, Inc.</vendor>
<homepage href="http://java.sun.com/javase/technologies/desktop/javawebstart/demos.html"/>
<description>A minimalist drawing application along the lines of Illustrator</description>
<description kind="short">Draw Demo Short Description</description>
<icon href="images/draw.jpg"/>
<offline-allowed/>
</information>
<resources>
<j2se version="1.3+" href="http://java.sun.com/products/autodl/j2se"/>
<j2se version="1.3+"/>
<jar href="draw.jar" main="true" download="eager"/>
</resources>
<application-desc main-class="Draw"/>
</jnlp>
A second possibility is to use a launcher-program. An example is the Apache Commons Launcher. You can also write some launcher app yourself, but that's usually not worth the effort.
You might also consider using Commons-Launcher, which allows you to setup various environment settings, or perform pre-checks before calling your application.
http://commons.apache.org/launcher
Generally, we've approached this with a C or (when unix-only) shell wrapper. Not sure this will really work for you.
We also approach this by embedding the JRE in our product. Takes care of 99.9% of the cases (the other 0.1% of the time is a user explicitly changing our configuration to use a different JVM). Again, not sure that this is a reasonable solution for you.
In our case, there is significant amounts of native code (JNI and otherwise), so tailoring an installable image for each platform we support is required anyway. But if you're dealing with a pure-Java solution, you may simply have to document your minimum and tell people to get with the program (no pun intended) if they're to run your stuff. It's sorta like people complaining that my Mac won't run MSVC, or that my Linux box is having problems running World of Warcraft. That's just not the (virtual) machine the software is targeted for - you need to switch. At least in the Java world, we really can call this an upgrade, though, without hurting anyone's OS-religious feelings. (Try telling the Mac user to "upgrade" to Windows XP to run MSVC - there's a beat-down waiting to happen.)
You can require a Java version when running the Java command, e.g. java -version:1.6* com.me.MyClass. Not sure if this works on all releases of Java, but it works OK on 1.6 anyway.
An application built for a higher-version JRE will not run on a lower-version JRE. So you wouldn't be able to just add code to your application to check the JRE version - if the JRE version was incompatible, your JRE-version-checking code would not run in the first place.
What you'd have to do is have some sort of launcher application that is built for a lower-version JRE (1.3?) that checks the version and then launches your app if necessary. This sounds kind of kludgy to me.
What about checking the version during installation? Are you installing the app in a way that allows you to check environment variables, or do any sort of scripting?
For the launcher - Check the version in there.
Inside the APP; as above use System.getProperties();
Properties sProp = java.lang.System.getProperties();
String sVersion = sProp.getProperty("java.version");
sVersion = sVersion.substring(0, 3);
Float f = Float.valueOf(sVersion);
if (f.floatValue() < (float) 1.4) {
System.out.println("Java version too low ....");
System.exit(1);
}
...
Have a launching class compiled for Java 1.2 which invokes the real main() in your 1.6 classes. If an unsupported class exception is thrown them catch it and display a nice error message.
Here is the code to get the JRE version installed in a system.
var list = deployJava.getJREs();
var result = "";
result = list[0];
for (var i=1; i<list.length; i++)
{
result += ", " + list[i];
}
document.write("jre version : "+result);
System.getProperties() gives you a listing of JVM properties including the different version ids of the JRE, JVM and specification. This implemented for all versions of Java so should work regardless of version compiled in and version run in, or the implementation.
If you write a basic class to test the version, you can call this first in your main() launching class. It must really be basic functionality though or you might risk breaking it.
Hmm .. call me a boring guy, but what's wrong with using Launch4J or any other native launcher, for instance.
Use a native launcher to check the JVM version before actually running your code. Java only solutions (in my book) only make sense when you deal with developers; once you hit end-users, you'll realize that they dont care about Java or its technical details at all. If you would have written your application in GW-Basic they would not care less as long as your application works.
If Java 1.6 is not installed, lauchner4j will point the user to the download page for JDK 1.6. Thats probably more suitable for your problem than doing magic in Java.
I find that WinRun4J works quite well for me (but then again I may be biased since I wrote it:-)). This lets you specify a minimum and/or maximum version of java allowed. It will pop up a message box to the user if a suitable JRE version is not found (and the message is customisable).
All those above is too damn complicated.
Just go:
Properties props = System.getProperties()
props.list(System.out)
And you will see everything about your JVM, JRE, JDK and staff.
Or get a specific value by using:
//full list of possible props you can see if u run code above
String props = System.getProperty(prop)